Quick Answer
According to Tenable's published FAQ on the campaign, the group publicly tracked as TeamPCP open-sourced its npm worm, Mini Shai-Hulud, on 12 May 2026, and copycats are already active. Wiz and Snyk say the payload in the June attack on the @redhat-cloud-services packages appears to derive from that code, and Wiz found the binding.gyp wave that followed carried a payload consistent with it. This article walks through what that means structurally - why the threat model is changing, why traditional CVE-based scanners cannot catch fresh poisoned packages, and what indie builders shipping AI-generated code should actually do this week. Every claim below is attributed to a named source report; nothing in this post is original VibeDoctor research.
Why Open Sourcing a Worm Changes the Threat Model
The most material change is not the size of any one campaign. It is that the operational pattern is now reproducible by anyone. Tenable's "mini Shai-Hulud" FAQ notes that TeamPCP published the worm's source code on GitHub on 12 May 2026, and that copycat packages from separate actors appeared the same month. Wiz's analysis of the Miasma campaign against Red Hat's npm packages says its payload appears to be derived from that code, while warning that a copycat using the public tooling cannot be ruled out. StepSecurity's analysis of the binding.gyp wave (it calls the technique Phantom Gyp) describes the propagation mechanic in detail: the malware harvests npm publish tokens from a compromised developer and uses those tokens to push poisoned versions of every other package that developer maintains.
When that pattern was operated by one well-resourced group, the response was at least scoped. Take down the bad versions, publish IOCs, patch and move on. With the framework now public, the equivalent of off-the-shelf ransomware kits has arrived for the npm registry. The reasonable expectation is more frequent, smaller, less coordinated waves over the next several months.
The Pattern: One Stolen Login, One Trusted Org, Hundreds of Downloads
The mechanic the public reports describe is structurally simple. According to Wiz and Microsoft's Miasma write-up, the Red Hat wave began with one compromised Red Hat employee GitHub account. The attacker pushed commits to the RedHatInsights repositories and let the project's own GitHub Actions workflow publish the packages, so the malicious versions carried authentic provenance signatures.
Downstream consumers then installed the poisoned versions in the normal course of work, and the payload collected the credentials on each affected machine. Where those machines held npm publish tokens, the worm propagated. StepSecurity documents this propagation step explicitly in the binding.gyp wave, and found the malware writing files into .claude, .cursor and .gemini folders, poisoning the AI tools that write code.
The reason this is bad for vibe coders specifically is that AI coding assistants amplify dependency churn. AI-built projects can pull dozens of direct npm packages and hundreds more underneath, often suggested by the assistant rather than chosen deliberately. Every one of those is a potential blast radius if the framework gets reused against a different upstream.
Why Standard Scanners Were Blind
The gap is structural: the traditional npm security toolchain is built around known CVEs and published advisories. npm audit, Dependabot, Snyk, and Trivy all answer the same question: does this package have a published vulnerability in a database we track? They do not answer the more useful question for this kind of attack: should this version of this package be trusted at all?
| Defence | Catches Known CVEs | Catches Freshly Poisoned Versions | Catches Hallucinated / Squatted Names |
|---|---|---|---|
| npm audit | Yes | No - no CVE entry yet | No |
| Dependabot | Yes | No - relies on advisories | No |
| Snyk / Trivy | Yes | Partial - only after advisory is published | Limited |
| Registry-existence scanning | No - different problem | No - not the problem it solves | Yes - flags missing or freshly-created packages |
| Behavioural install monitoring | No | Partial - if behaviour is observed | Partial |
A freshly poisoned package version has no CVE because nobody has triaged it yet. It has no advisory because nobody has reported it. It passes every default vulnerability scan with a clean bill of health for hours or days while the worm spreads. The toolchain assumption that "no published CVE means safe" is the assumption the worm operators are exploiting.
The Stats: How Big the Sprawl Already Was
None of this is happening on a clean field. GitGuardian's State of Secrets Sprawl 2026 report documents the baseline volume of credentials already living in public code, internal repos, and collaboration tools. The numbers in that report - which we are linking, not republishing - are the input data for any worm that successfully runs a credential scrape on enough developer machines.
The supporting illustration of why credential hygiene matters even outside attacker-controlled malware came in a different incident this year. Brian Krebs's reporting on AWS GovCloud keys for CISA systems leaked on GitHub made the wider point: keys to the federal cybersecurity agency's cloud accounts sat in a contractor's public repository, and stayed valid for about 48 hours after it was taken down. Once a worm has the harvested credential pool from infected developer machines, sorting which ones unlock real infrastructure is a tractable problem - and Tenable's FAQ cites Unit 42 on TeamPCP's announced partnership with the Vect ransomware group.
The takeaway is not a specific number. It is that the baseline rate of exposed credentials, combined with an open-sourced worm and AI tools that confidently pull packages developers do not review, is a strictly worse environment than the one most security playbooks assume.
What Vibe Coders Should Actually Do This Week
// ❌ The pattern that quietly broke for a lot of teams in 2026
// "Trust the lockfile, scan after install, react to advisories."
// - install runs immediately, including any postinstall scripts
// - audit happens later, after CVE entries exist
// - editor persistence (if any) is invisible to npm-level tooling
# ✅ A more cautious default for AI-generated projects
# "Verify the package, install without scripts, then enable scripts deliberately."
npm info <package> # confirm it exists, check publish date and maintainers
npm install --ignore-scripts <package> # install but do not run lifecycle scripts
# read node_modules/<package>/package.json - inspect scripts.{preinstall,install,postinstall}
# and look for a binding.gyp file: npm runs node-gyp for it even with no install script
# run the scripts (npm rebuild <package>) only if there is a real reason
- Pin exact versions. Replace
^and~ranges with exact versions inpackage.jsonand commit the lockfile. This shrinks the window where a freshly poisoned version slips into a CI build before advisories exist. - Treat lockfile churn as a code review event. Reviewing
package-lock.jsondiffs is not glamorous, but unexplained version bumps are the most boring tell for supply chain compromise. - Use
--ignore-scriptswhen adding new dependencies. Inspect the lifecycle scripts of any package suggested by an AI assistant before letting them run. - Audit editor configuration after any incident. The cleanup checklist in Snyk's Miasma write-up says to remove attacker-planted hooks in editor and agent config, such as
.claude/settings.jsonand.vscode/tasks.json, before touching credentials. Those files live outsidenode_modules, so they need checking even when npm audit is clean. - Verify imports against the registry. Tools like VibeDoctor's Vibe Check check every import in AI-generated codebases against the live npm registry and flag packages that do not exist, brand-new packages with almost no downloads, and names one or two letters off a popular package. The check runs against your repo without needing to install the packages first. Free to sign up.
- Rotate any token that lives on a machine where you ran an affected version. Order of operations matters - see the Snyk article for the recommended sequence to avoid the wipe-on-revoke behaviour Microsoft documented.
FAQ
If the worm framework is public, how worried should an indie hacker actually be?
The honest answer from the public reports is that the threat model widened, not deepened. The same group running coordinated waves is still the most capable operator. But because the framework is reproducible, smaller, opportunistic copies become likely. For a solo founder, that means the volume of low-skill attempts against npm is the variable that changes, not the maximum sophistication.
Will npm audit or Dependabot catch a freshly poisoned package?
No - not until an advisory is published. Both tools answer "does this package have a known vulnerability" by looking at databases that lag the attack window. StepSecurity's Phantom Gyp analysis documents a related gap: the binding.gyp technique bypasses most install-script checks, because the package.json has no install script to flag. A registry-existence and metadata-quality check is a different defence aimed at the window before advisories arrive.
Which sources should I track for ongoing IOCs?
The Microsoft Threat Intelligence post for the Miasma wave, the StepSecurity post for Phantom Gyp, the Snyk write-up for cleanup steps, the Wiz analysis for the link to the open-sourced worm, and the Tenable FAQ for victim scope and attribution context. All five are linked in this article.
Does locking my dependencies fully protect me?
It reduces blast radius but does not eliminate it. Pinning exact versions and committing the lockfile prevents passive uplift to a newer poisoned version. It does not protect you against installing a poisoned version directly the first time, against an AI assistant adding a brand-new bad dependency, or against postinstall scripts already executed before pinning. Lockfiles are necessary but not sufficient.
Why are credentials in repos relevant to npm attacks?
The two problems compound. GitGuardian's State of Secrets Sprawl 2026 documents how widespread credential exposure already is across public and private repos. Krebs's reporting on the CISA GovCloud key leak illustrates that this is not only an indie-hacker problem. A worm that successfully scrapes credentials from developer machines is more dangerous in an environment where matching credentials are also sitting in old repos and CI logs waiting to be cross-referenced.