A trusted maintainer, a compromised account
On August 4, 2026, attackers compromised the GitHub account of Jaredwray, a maintainer trusted with publish access to some of the most heavily used low-level utility packages in the JavaScript ecosystem. Keyv alone pulls roughly 127 million downloads a week; flat-cache and file-entry-cache each pull over 550 million. None of these packages are famous. That is precisely why the attack worked: they are invisible infrastructure buried three or four dependency layers deep in build pipelines that almost nobody audits by hand, exactly the profile the earlier Shai-Hulud campaign exploited when it first surfaced.
Within an hour of the initial compromise, the payload had self-replicated across more than 440 packages spanning 2,200 versions, using stolen publish credentials to push infected releases faster than any human review process could catch up. Researchers estimate the exposure at over 2 billion monthly installs once transitive dependencies are counted. A small number of malicious versions were reportedly still live on the npm registry at the time researchers published their findings, which means the cleanup window is still open and organizations that have not audited their lockfiles are still exposed.
How the worm actually works
The infection runs in two deliberate stages. The first, a lightweight dropper called setup.mjs, downloads a standalone Bun runtime and re-executes the payload through it rather than through Node.js. That choice is the tell of an attacker who has studied enterprise defenses: most endpoint detection and response tooling is tuned to watch Node.js process trees for anomalous behavior, and a parallel Bun runtime slides underneath that visibility. Any detection rule written only against node.exe or node process ancestry will miss this campaign entirely.
The second stage, a heavily obfuscated 728 KB file named Math_Symbol.js, does the real damage through four coordinated modules: a credential harvester that pulls npm tokens, GitHub credentials, cloud provider secrets and SSH keys off the host; an execution coordinator; a publishing-metadata handler; and a package infector that uses the harvested credentials to republish the worm into any other package the compromised account can touch. It also drops persistence into developer tooling config files, including .claude/settings.json and .vscode/tasks.json, so the infection survives a simple reinstall and re-triggers the next time those tools run.
Why this campaign scales differently
What separates this from a typical typosquatting or dependency-confusion attack is the self-propagation loop. Traditional supply-chain compromises are largely static: an attacker poisons one package, and the blast radius is whoever installs that exact package and version. Shai-Hulud turns every successful infection into a new launch point, because the stolen credentials let it republish itself under other maintainers' names using their own legitimate publish rights. That is a worm in the literal sense, not just a poisoned package, and it means the affected-package count keeps climbing after the initial compromise rather than staying fixed.
It is also the second time this exact worm family has resurfaced in 2026, following an earlier wave that compromised hundreds of packages under a different set of maintainer accounts. That recurrence matters more than the specific package list. It tells us the initial access vector, compromising individual maintainer credentials through phishing, token leakage or reused passwords, has not been closed off anywhere in the ecosystem, and npm's registry-level defenses have not kept pace with an attacker who has now demonstrated the technique works twice.
What to check right now
Start with the published indicators of compromise: the file names setup.mjs and Math_Symbol.js, the process chain of node spawning setup.mjs which spawns bun, the persistence locations in .claude/settings.json and .vscode/tasks.json, and network traffic to the exfiltration endpoint at npm-cache[.]com over port 443. Any CI/CD runner, developer laptop or build server that installed keyv, flat-cache, file-entry-cache, cacheable-request or any of the other 440 flagged packages since August 4 needs to be treated as potentially compromised, not just patched by bumping the dependency version.
Credential rotation is the step teams skip and shouldn't. Because the malware specifically targets npm publish tokens, GitHub personal access tokens, cloud provider keys and SSH keys, simply removing the infected package and reinstalling a clean version does nothing if the credentials it stole are still valid. Rotate npm and GitHub tokens for every account that touched an affected machine, audit cloud IAM logs for unusual API activity in the same window, and check whether any of your own packages were republished under compromised maintainer credentials during the propagation window.
The governance gap this exposes
Most enterprise software composition analysis tools are built to flag known-bad packages after the fact, once a CVE or advisory exists. Shai-Hulud's self-propagating design means that model is structurally too slow: by the time a package makes it onto a blocklist, it may have already republished itself under a dozen other names. The organizations that caught this fastest were the ones running real-time SBOM monitoring against live registry changes rather than periodic dependency scans, and that gap between periodic and continuous scanning is now a material risk decision for any CTO running a JavaScript-heavy stack.
The deeper fix is upstream of any individual company's tooling. npm's publish-security model still relies heavily on individual maintainer account hygiene for packages that sit at the center of the dependency graph, with no equivalent of code-signing or multi-party publish approval enforced broadly across the registry. Until that changes at the ecosystem level, enterprises should treat every low-level utility dependency, however boring and however many downloads it has, as a potential single point of compromise, and budget for continuous monitoring accordingly rather than treating supply-chain security as a one-time audit line item.
