A developer installs what appears to be a routine JavaScript dependency. Before the installation even finishes, hidden code executes, searches the workstation or build server for credentials, and checks whether the victim has permission to publish other npm packages.
If it finds a valid npm publishing token, the malware uses that access to infect additional packages and repeat the process.
That is exactly what happened on August 4, 2026, when malicious code first appeared in keyv@6.0.0 before rapidly spreading across hundreds of npm packages maintained by multiple organizations. Researchers have linked the campaign to the Mini Shai-Hulud malware family, although the threat actor and the initial compromise remain unknown.
Unlike a typical malicious npm package, this campaign is self-propagating. Once it steals publishing credentials from one maintainer, it can automatically publish infected versions of every package that maintainer controls, allowing the malware to spread across the ecosystem within minutes.
According to SafeDep’s latest update, researchers have identified 2,234 malicious package versions spanning 444 package names across multiple npm organizations. Aikido reported a different total based on its own monitoring, illustrating how quickly the campaign evolved as malicious releases were published, removed, and replaced throughout the day.
Those numbers represent malicious package versions, not confirmed infected systems. Whether a workstation or CI environment was compromised depends on the exact dependency versions installed and whether the malicious installation script executed.
A normal install becomes an infection
The first confirmed malicious release was keyv@6.0.0, which introduced a malicious preinstall hook that executed setup.mjs. Because npm automatically runs lifecycle scripts during installation, developers could become infected simply by running npm install if an affected dependency was present.
The initial script checks whether the Bun JavaScript runtime is installed. If it is missing, the malware downloads Bun directly from its legitimate GitHub releases before launching a much larger compiled payload stored in Math_Symbol.js.
Using trusted infrastructure makes the attack harder to detect. Instead of downloading malware from suspicious domains, the installer retrieves Bun from GitHub, while stolen data is reportedly exfiltrated through attacker-controlled GitHub repositories and GitHub Actions artifacts.
Keyv alone receives roughly 127 million weekly downloads, according to Aikido. While download counts do not reflect the number of infected systems, they illustrate how quickly a poisoned dependency can ripple throughout the JavaScript ecosystem.
Why this malware spreads so quickly
The payload searches developer workstations and CI runners for valuable credentials, including GitHub tokens, npm publishing tokens, cloud credentials, Kubernetes secrets, HashiCorp Vault tokens, SSH keys, database credentials, Terraform state files, password manager databases, Slack tokens, Stripe credentials, and other sensitive development assets.
The stolen npm and GitHub tokens are what transform this malware into a worm.
If an infected developer maintains other npm packages, the malware can automatically modify those projects, inject the malicious files, publish new versions under the victim’s own account, and continue spreading. Every newly compromised package can then infect additional maintainers and repeat the cycle.
SafeDep observed the worm moving between organizations every few minutes, with entire package namespaces reportedly republished in rapid succession. That behavior strongly suggests automated propagation rather than an attacker manually modifying each package.
Even organizations that never publish npm packages may still be affected. The malware collects a broad range of credentials that could later be used to access cloud infrastructure, source code repositories, production environments, or internal systems long after the malicious package has been removed.
Claude Code and VS Code added another execution path
The npm installation hook was not the campaign’s only execution method.
Researchers also identified repository configuration files designed for Claude Code and Visual Studio Code. A Claude Code session hook could invoke the malicious script when a trusted session started, while a VS Code task was configured to run when the project folder opened.
These mechanisms do not execute automatically in every environment. VS Code generally blocks automatic tasks inside untrusted workspaces, while Claude Code applies trust controls before honoring repository-provided settings. However, once a developer trusts the project or approves the configuration, those protections may no longer apply.
That means responders should inspect both installed npm packages and local clones of affected repositories. Simply uninstalling a malicious dependency may not remove repository-based execution paths already present on a developer workstation.
What security teams should do
Organizations should review dependency lockfiles and resolved package versions instead of relying on whichever version is currently marked as latest in the npm registry. During the incident, registry tags changed repeatedly as malicious releases were unpublished and replaced.
- Compare dependency lockfiles against the affected package lists published by the researchers.
- Search developer workstations and CI runners for
setup.mjs,Math_Symbol.js, unexpectedpreinstallhooks, and suspicious Claude Code or VS Code project configuration. - Treat any workstation or CI environment that executed an affected release as potentially compromised.
- Remove the malware’s credential revocation watcher before rotating exposed tokens or keys, following SafeDep’s published guidance.
- Review npm and GitHub publishing history for unauthorized releases across every package maintained by affected accounts.
- Rotate npm, GitHub, cloud, Vault, Kubernetes, SSH, database, and other credentials that may have been accessible.
- Disable unnecessary package lifecycle scripts wherever practical and require explicit approval before repository-supplied developer tooling executes.
The order of response is important. SafeDep warned that the malware installs a local watcher capable of reacting when credentials are revoked. Rotating tokens before isolating the host and removing that component could trigger additional attacker-controlled activity.
Trusted pipelines were not enough
One of the more concerning aspects of the campaign is that several malicious releases reportedly carried valid OpenID Connect (OIDC) and Supply-chain Levels for Software Artifacts (SLSA) provenance because they were built through legitimate GitHub Actions release workflows.
In other words, the build process itself was authentic. The problem was that malicious code had already entered the trusted pipeline before the package was built and signed.
That distinction matters. Provenance can verify where a package came from and how it was produced, but it cannot guarantee that the source code entering the build process was safe.
This latest campaign continues a growing trend of attacks targeting software supply chains instead of end users directly. Earlier this year, BreachNews covered the Miasma supply chain attack, the OpenAI incident linked to Mini Shai-Hulud, and the original Mini Shai-Hulud campaign. Researchers have not attributed the current wave to a specific threat actor, and the method used to compromise the first publishing account remains unknown.
