NPM under attack: the worm that steals credentials and checks your CI pipelines

On August 4, 2026, a npm poisoning campaign was detected that began with the malicious release keyv @ 6.0.0 and quickly expanded by multiple package names and organizations. It was a worm designed to steal credentials., which was activated by a pre-installation script and deployed a packaged binary capable of exfiltering tokens and repository keys, records, clouds and continuous integration runners (CI), as well as including mechanisms to publish new versions with stolen identities.

The telemetry of independent researchers did not agree on a single final count: SafeDep verified hundreds of malicious versions in dozens of packages, Aikido presented an even greater count and other observations recorded partial points. The total number of packages or versions reported indicates scale, but does not amount to the number of victim systems; such determination requires checking the exact version resolved on each machine and, above all, whether the life cycle script was run.

From the technical point of view, the campaign used a pre-install file that invoked setup.mjs and deployed a compiled bundle that sought runtimes like Bun, downloaded components and then executed code that explored the runner memory, read secrets in files and environment variables, and placed a "watcher" whose function was to observe tokens retorations. That watcher poses an important operational risk: first rotating the credentials can fire a local controller supplied by the attacker, so the response teams should neutralize the malware before starting the rotation.

The attack surface was greater because the compromised repository also contained hooks for editors and development environments: Claude Code and Visual Studio Code configuration files that, if trusted, can run setup.mjs when opening the project. In development environments and in CI runners there are two independent vectors - the npm installer and the workspace configuration - and both must be considered potentially dangerous.

The campaign revealed that the guarantees of provenance and signature of build are not a panacea: several of the poisoned releases carried valid signatures and SLSA atstations because the publication flow passed through the legitimate pipeline of the project. An attestation that verifies the construction process does not on its own guarantee that the source code that entered that process is safe, and therefore the verification of the supply chain should include controls on the source repository and on who controlled the publication credentials.

To detect exposure in your environment, it is essential to use the local sources: inspect package-lock.json, npm-shrinkwrap.json, yarn.lock and pnpm-lock.yaml to locate the exact versions solved; check whether the manifest contained a pre-install script or suspicious files (e.g. setup.mjs or unusual names included in the publication); and analyze CI and installation logs to see if life-cycle scripts were executed. Do not rely on public lists of "latest" packages or on space name blocks; the verification should be by exact name and version.

The immediate technical response should combine malware isolation and removal with a coordinated credentials rotation plan. First, quarantine suspicious machines and runners and search and remove the watcher or any persistent device that may react to the revocation. Then, rote keys, tokens and certificates committed. If it is broken without first neutralizing the watcher, there is a risk of activating the attacker's code that takes advantage of the rotation. Finally, reconstruct artifacts and containers from trusted sources and from verified code trees.

In CI / CD infrastructure and development policies, there are concrete measures to reduce future exposure: update npm customers that block default life cycle scripts when compatible with their flow, disable the automatic execution of workspace tasks in VS Code and Claude Code, adopt ephemeral tokens and OIDC for deployments, restrict publication permits in records and require multifactor authentication and human reviews for critical releases. Effective security combines tools (e.g. locking of lifecycle scripts), policies (minimum privilege principle) and processes (review of commitments and control of access to credentials).

Packaging maintenance teams must audit their work tree and the history of commitments looking for changes that have spread suspicious files to multiple subpackages. Pay attention to commitments signed or verified by bots that, even if they show a verification badge, do not identify who controlled the credential that signed the action. Signature verification is necessary but not sufficient; combine that signal with controls over who had access to the pipeline and with revisions of the integrity of the source code.

For consumers and organisations, the immediate practical recommendation is to identify specific instances that could install affected versions and determine whether installation scripts were executed. If you confirm execution, isolate the machine and the runner, preserve evidence and proceed to the cleaning and rotation of secrets in accordance with the order described. If you are not sure of the state of execution, treat the machines as potentially exposed to prove otherwise with images or rebuilds from clean sources.

To deepen the signature verification practices and the recommended SLSA framework for supply chain attentions, see GitHub's official documentation on signature verification About commit signature verification and the principles of the SLSA project in slsa.dev. For campaign analysis and repository commitments, resources such as the Semgrep blog collect useful examples and rules that can be applied in repository scans; see your publications page at Semgrep Blog.

This incident highlights a key lesson: the supply chain defenses must be proactive, focused on accuracy (resolved versions and lockfiles) and on the hygiene of credentials. Organizations should review their publishing processes, tighten pipelines, limit the blast radius of tokens and prepare response playbooks that contemplate the orderly rotation of secrets campaign after the elimination of any monitoring mechanism installed by the attacker.