A worm-like spam campaign sprayed the npm registry with junk packages at massive scale, pushing the count from “tens of thousands” into the “sixty-thousand plus” range. Consequently, developer search results and CI/CD pipelines face more noise, more dependency bloat, and new openings for typosquats to slip through. Therefore, engineering leaders should treat public registries as hostile input and enforce strict allowlists, provenance verification, and lifecycle-script controls across the supply chain.
𝐖𝐡𝐚𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐞𝐝: 𝐚 𝐰𝐨𝐫𝐦-𝐬𝐭𝐲𝐥𝐞 𝐬𝐩𝐚𝐦 𝐞𝐱𝐩𝐥𝐨𝐢𝐭
Researchers traced a coordinated “IndonesianFoods” campaign that auto-publishes fake Next.js-looking projects every 7–10 seconds, yielding roughly 12 packages per minute. As a result, the registry accumulated more than 67,000 packages tied to dozens of accounts. Notably, payloads stay dormant unless a user manually runs a file such as “auto.js” or “publishScript.js,” which then loops through publish steps and floods the registry again. Consequently, install-time scanners miss it because nothing executes during npm install.
𝐖𝐡𝐲 𝐭𝐡𝐢𝐬 𝐚𝐭𝐭𝐚𝐜𝐤 𝐬𝐭𝐢𝐥𝐥 𝐰𝐨𝐫𝐤𝐬
Because the code avoids postinstall hooks, default defenses don’t trigger. Moreover, each package looks like a normal template with standard dependencies and README files. Meanwhile, inter-package dependencies create a self-replicating web: install one spam module and npm resolves many more, amplifying bandwidth and clutter. Therefore, scanners and manual reviews must add signals beyond lifecycle-script analysis, including dormant file patterns and suspicious dependency graphs.
𝐌𝐨𝐧𝐞𝐭𝐢𝐳𝐚𝐭𝐢𝐨𝐧 𝐭𝐡𝐫𝐨𝐮𝐠𝐡 𝐓𝐄𝐀 𝐩𝐫𝐨𝐭𝐨𝐜𝐨𝐥 𝐬𝐢𝐠𝐧𝐚𝐥𝐬
Investigators found tea.yaml files pointing to TEA protocol accounts in some attacker-controlled packages, suggesting the spam inflated on-chain “impact” scores to earn token rewards. Consequently, the registry got flooded for profit even without outright malware execution. Therefore, defenders should flag tea.yaml and similar reward-scheme files when they appear in otherwise trivial template packages.
𝐇𝐨𝐰 𝐭𝐡𝐞 𝐰𝐨𝐫𝐦 𝐩𝐮𝐬𝐡𝐞𝐬 𝐬𝐨 𝐦𝐮𝐜𝐡 𝐣𝐮𝐧𝐤
First, the script removes “private”: true from package.json, which normally blocks publication. Then it generates random versions and names, and finally runs npm publish in a tight loop. Because npm’s own docs confirm that “private: true” prevents publishing, removing it helps the flood. Consequently, a single execution can push thousands of packages per day.
𝐖𝐡𝐚𝐭 𝐦𝐚𝐤𝐞𝐬 𝐭𝐡𝐢𝐬 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐭 𝐟𝐫𝐨𝐦 𝐒𝐡𝐚𝐢-𝐇𝐮𝐥𝐮𝐝 𝐢𝐧𝐜𝐢𝐝𝐞𝐧𝐭𝐬
Recent npm compromises like “Shai-Hulud” delivered credential theft and self-replication across maintainers; however, this spam wave focuses on registry pollution and monetization, not immediate code execution. Still, both trends erode trust and pressure teams to raise their baseline. Therefore, treat both as signals that default npm hygiene isn’t enough.
𝐈𝐧𝐝𝐢𝐜𝐚𝐭𝐨𝐫𝐬 𝐲𝐨𝐮 𝐜𝐚𝐧 𝐩𝐮𝐥𝐥 𝐢𝐧𝐭𝐨 𝐬𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐭𝐨𝐨𝐥𝐢𝐧𝐠
Look for sudden bursts of new packages from small clusters of publishers; identical Next.js templates with unreferenced JavaScript files named auto.js or publishScript.js; repeated dependency chains among obviously unrelated packages; and name patterns (e.g., Indonesian names/foods, or random English pairs). Additionally, watch for removal of the “private” flag, randomized version bumps, and publish loops observable via registry telemetry.
𝐈𝐦𝐦𝐞𝐝𝐢𝐚𝐭𝐞 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐦𝐞𝐧𝐭: 𝟐𝟒 𝐡𝐨𝐮𝐫𝐬
Freeze risky CI/CD jobs, and switch installs to a private proxy or cache that enforces allowlists. Then rebuild lockfiles from approved artifacts only; after that, rotate npm tokens and revoke stale PATs. Moreover, set npm to ignore lifecycle scripts by default; only allow specific scripts when required for trusted packages. Finally, block the offending publisher accounts and dependency patterns in your proxy rules.
𝐃𝐞𝐟𝐞𝐧𝐬𝐢𝐯𝐞 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠, 𝐭𝐡𝐞 𝟕 𝐜𝐡𝐞𝐜𝐤𝐛𝐨𝐱𝐞𝐬 𝐭𝐡𝐚𝐭 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐦𝐨𝐯𝐞 𝐭𝐡𝐞 𝐧𝐞𝐞𝐝𝐥𝐞
-
Enforce a curated allowlist in a private registry or artifact proxy; quarantine new packages by default.
-
Require npm provenance on new third-party packages and verify attestation bundles with Sigstore/cosign.
-
Adopt SLSA-aligned build pipelines and promote dependencies via policy-driven stages.
-
Disable lifecycle scripts globally; allow only vetted packages to run them.
-
Prohibit postinstall behaviors in production builds; fail CI if scripts attempt network egress.
-
Run installs in an isolated container or sandbox to protect host secrets.
-
Track an “unknown dependency exposure” KPI and reduce it each sprint.
𝐃𝐞𝐭𝐞𝐜𝐭𝐢𝐨𝐧 𝐚𝐧𝐝 𝐫𝐞𝐬𝐩𝐨𝐧𝐬𝐞: 𝐰𝐡𝐚𝐭 𝐲𝐨𝐮𝐫 𝐛𝐥𝐮𝐞 𝐭𝐞𝐚𝐦 𝐰𝐚𝐧𝐭𝐬
Instrument the SIEM for npm lifecycle anomalies: unexpected child processes during builds, curl/wget from node hooks, and credential/secret access shortly after dependency changes. Additionally, monitor for waves of new dependencies added by a single user; set cooldowns for newly published packages; and flag sudden lockfile churn across teams. Where possible, require provenance and reject packages lacking attestations.
𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 𝐰𝐨𝐫𝐤𝐟𝐥𝐨𝐰: 𝐬𝐚𝐟𝐞𝐫 𝐩𝐚𝐜𝐤𝐚𝐠𝐞 𝐬𝐞𝐥𝐞𝐜𝐭𝐢𝐨𝐧
Therefore, search smarter: verify maintainers, inspect commit histories, and prefer packages with signed provenance and stable release cadences. Moreover, sandbox installs locally, test without network egress, and avoid copying commands that tell you to “run node auto.js to complete setup.” Finally, adopt semantic-range pinning that prevents surprise upgrades introduced by broad version specifiers.
𝐀𝐜𝐭𝐢𝐨𝐧 𝐜𝐡𝐞𝐜𝐤𝐥𝐢𝐬𝐭
• Today: enable ignore-scripts, point CI to a private allowlisted proxy, rotate tokens, and regenerate lockfiles from approved cache only.
• This week: require provenance attestations for new third-party packages; set minimum-age cooldowns; and add policy gates for postinstall.
• This month: migrate to SLSA-aligned promotion stages; build SBOMs; and audit developer machines for rogue global npm config.
The registry flood doesn’t need classic malware to harm you. Instead, it weaponizes scale and entropy to pollute discovery and clog pipelines. Consequently, teams that treat npm like any external data feed verify, stage, promote reduce exposure while keeping velocity.
𝐅𝐀𝐐𝐬
Q: Is this an immediate code-execution risk?
A: Not by default. The spam relies on manual execution or social tricks; nevertheless, it creates cover for future pivots and typosquats. Therefore, harden now and don’t assume “no postinstall” equals “no risk.”
Q: How do we verify npm package provenance quickly?
A: Require provenance generation at publish time and verify Sigstore bundles (cosign / audit signatures). Then fail CI on missing or untrusted attestations.
Q: Does SLSA help for JavaScript teams?
A: Yes. Use SLSA-style promotion between dev/test/prod and require attestations at each stage. Therefore, provenance becomes enforceable policy, not a suggestion.
