TeamPCP Open-Sourced Their npm Worm: What It Means for Vibe Coders

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 attributes the two recent npm campaigns (publicly nicknamed Miasma and Phantom Gyp) to the same group and notes that the underlying framework was published publicly on 12 May 2026. StepSecurity's analysis of the Phantom Gyp wave 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 Tenable's FAQ and Microsoft's Miasma write-up, the first wave began with a single set of compromised credentials at a vendor whose npm publish pipeline carries inherent trust with downstream consumers. Once inside, the attacker pushed poisoned versions through the vendor's normal release process, so the malicious code shipped with the same provenance signals legitimate releases carry.

Downstream consumers - including AI coding tools that auto-pull popular packages - then installed the poisoned versions in the normal course of work, exfiltrating any credentials present on each affected machine. Where those machines held npm publish tokens, the worm propagated. StepSecurity documents this propagation step explicitly in the Phantom Gyp wave.

The reason this is bad for vibe coders specifically is that AI coding assistants amplify dependency churn. Most indie projects built with Bolt, Lovable, Cursor, v0, or Replit pull dozens to hundreds of npm packages, 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

Every public report stresses the same gap: the traditional npm security toolchain is built around known CVEs. 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?

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 valid credentials already living in public code, private repos, container images, and CI logs. 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 a CISA administrator leaking AWS GovCloud keys on GitHub made the wider point: even the federal cybersecurity agency leaves long-lived cloud credentials in public repos. Once a worm has the harvested credential pool from infected developer machines, sorting which ones unlock real infrastructure is a tractable problem - exactly the kind of work the public reports say is now coordinated with a 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 downloads
npm install --ignore-scripts <package>      // install but do not run lifecycle scripts
// read node_modules/<package>/package.json - inspect scripts.{install,postinstall,prepare}
// re-run with scripts enabled only if there is a real reason

1. Pin exact versions. Replace ^ and ~ ranges with exact versions in package.json and commit the lockfile. This shrinks the window where a freshly poisoned version slips into a CI build before advisories exist.
2. Treat lockfile churn as a code review event. Reviewing package-lock.json diffs is not glamorous, but unexplained version bumps are the most boring tell for supply chain compromise.
3. Use --ignore-scripts when adding new dependencies. Inspect the lifecycle scripts of any package suggested by an AI assistant before letting them run.
4. Audit editor configuration after any incident. Per the cleanup checklist in Snyk's Miasma write-up, the persistence path bypasses the package boundary entirely - so editor configs need to be checked even when npm audit is clean.
5. Verify imports against the registry. Tools like VibeDoctor (vibedoctor.io) scan AI-generated codebases for hallucinated imports, freshly-published packages, and the dependency patterns that supply chain attackers reuse. The check runs against your repo without needing to install the packages first. Free to sign up.
6. 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