Two malicious npm campaigns surfaced within three weeks of each other. Read the headlines and they merge into one message: npm packages are dangerous. Read the reports and they differ on the point that decides whether a developer ever gets a chance to stop them.
Case one: the worm that needs your trust
A credential-stealing worm first appeared in keyv@6.0.0 and spread beyond the Keyv and Cacheable namespaces into hundreds of packages on 4 August 2026.
The malicious release added node setup.mjs as a preinstall command while leaving the compiled library code unchanged. Stage one checks for the Bun runtime, downloads it if needed, and hands off to a compiled bundle of 727,680 bytes. According to SafeDep’s analysis, that bundle harvests GitHub, npm, cloud, Vault, Kubernetes, database and private-key material, reads GitHub Actions runner memory, and carries npm publishing machinery of its own, which is how it spreads further.
The repository also retained separate Claude Code and Visual Studio Code hooks. These matter, and so does the qualification the report attaches to them: they “can execute the payload once a user trusts the workspace or permits the project configuration.”
There is a gate. Someone has to walk through it.
Case two: the one that does not ask
On 21 August, TrendAI reported fourteen trojanized npm packages posing as calendar and streak utilities. They work: the promised functionality is there, which is what keeps them installed.
Underneath, the entry file acts as a loader for a Linux backdoor disguised as a native math accelerator. The filename varies across packages (math-core.bin, calc-math.dat, calc-cache.bin and others), but the contents are the same beacon.
The mechanism is where this diverges from case one. In the researchers’ words: “When the module loads, it locates the bundled binary, marks it executable, and launches it as a detached background process. No install hook function call is needed; a single import anywhere in the dependency graph, even a transitive one, is enough to execute the payload.”
No install hook. No trust prompt. No exported function anyone has to call. An import three levels down in a dependency you never chose is sufficient.
Why the difference is the story
Both are npm supply-chain attacks. Bundling them into one warning loses the only part that changes what you do.
Case one is slowed by a human decision. npm 12 blocks unapproved dependency lifecycle scripts by default, and the editor hooks need someone to trust the workspace. Older npm clients and other install paths that permit lifecycle scripts stay exposed, so the protection is real but conditional.
Case two has no such step. The payload runs on import, which means the defences that matter are the ones that do not depend on anyone noticing anything: dependency pinning, lockfile discipline, and knowing what is actually in your tree.
Anyone who walks away with “be careful with npm packages” has skipped the half that tells them where to spend the effort.
The scale numbers do not agree, and the report says so
This is where the story gets quoted badly, so here is the full picture.
SafeDep verified 353 poisoned versions across 79 package names. Its own monitoring put the wider footprint at 442 versions across 353 names. Aikido later reported at least 868 packages across 1,381 versions.
Three counts, three sources, and the report is explicit that “neither broader total was independently reproducible from a complete public list at the reporting cutoff.”
It adds a second caution that matters more than the spread: those totals “count malicious package artifacts, not victim systems. They establish campaign scale but do not show how many machines installed or executed the payload.”
So if you see a single confident figure for this campaign, it has been picked from a set of three that disagree, and it is counting packages rather than infections either way.
The counterintuitive remediation step
This is the most useful sentence in either report, and it is easy to miss.
The payload installs a credential-revocation watcher. SafeDep advises responders to remove that watcher before rotating exposed tokens and keys, because revocation is what triggers it: rotating first can run an attacker-supplied local handler.
The instinctive response to a credential-stealing compromise is to rotate everything immediately. Here that instinct fires the trap.
Socket’s assessment of who needs to act is broad: “any workstation or runner that executed an affected version should be treated as credential-exposed.”
Why a package list will not save you
The report notes that the registry changed too quickly to support a fixed campaign-wide list. Hours after the initial findings, earlier releases had been restored as latest for at least nine packages from SafeDep’s initial set.
The practical consequence: exposure checks have to use exact package names, resolved versions and lockfiles, not a cached list of current tags. A namespace-level blocklist risks both missing poisoned versions and flagging releases that were never affected.
That is a familiar shape. A list that looks authoritative, is out of date by the time it is read, and produces confident answers in both directions.
What to take from this
Find out whether your install paths run lifecycle scripts. If you are on an npm version that blocks them by default, case one is gated for you. If you are not, it is not.
Know what a transitive import can reach. Case two needs nothing but a module load somewhere in the graph, which makes dependency depth a security property rather than a tidiness one.
And if you ever act on a credential-stealing incident, read the remediation order before rotating. This time, the obvious first move was the one that triggers the payload.
Sources
- The Hacker News, “Keyv-Linked npm Worm Poisons Hundreds of Packages, Plants Claude Code and VS Code Hooks”, 4 August 2026: https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html (retrieved 26 August 2026). Source of the keyv@6.0.0 origin, the preinstall mechanism and payload size, the harvested material, the three conflicting scale figures and the report’s own caveats about them, the editor-hook qualification, the revocation-watcher remediation order, the Socket exposure assessment, and the note on changing registry tags.
- The Hacker News, “14 Trojanized npm Packages Drop RedC2 4.0 Linux Backdoor With AI-Assisted C2”, 21 August 2026: https://thehackernews.com/2026/08/14-trojanized-npm-packages-drop-redc2.html (retrieved 26 August 2026). Source of the fourteen packages, the loader mechanism quoted verbatim, the varying binary filenames, and the identification of the payload as the RedShell Linux beacon.
