Keyv npm supply-chain worm
How Automic Vault would have prevented the Keyv npm credential theft.
The Keyv worm used npm install hooks to steal developer credentials, then used those credentials to poison more packages and repositories. Automic Vault would have kept protected secrets behind an explicit handoff, denying the worm the tokens it needed to steal and spread.
Published August 4, 2026
With supported secrets moved out of plaintext files and npm installs running from a terminal with no automatic secret access, Automic Vault would have denied the worm the GitHub, npm, and AWS credentials stored behind its gate. That breaks both the credential theft and the stolen-token path used to republish packages.
Incident Facts
local execution- Date
- August 4, 2026
- Trigger
keyv@6.0.0and related packages added"preinstall": "node setup.mjs". The Keyv repository also contained Claude Code and VS Code hooks that ran when a developer opened it.- Observed scope
- SafeDep confirmed 2,234 poisoned versions across 444 package names while the response was active. The linked breaking report described at least 868 affected packages.
- Targets and spread
- GitHub, npm, AWS, GCP, Azure, Kubernetes, Vault, Stripe, Slack, private keys, and database credentials. Stolen npm and GitHub tokens let the worm publish more releases and modify more repositories.
What Happened?
incident recordAttackers pushed malicious files into the Keyv source repository and published keyv@6.0.0 through the legitimate GitHub Actions release workflow. The npm package carried valid provenance because the real workflow built the poisoned source.
A bare npm install ran setup.mjs before the install finished. The dropper fetched the Bun runtime when necessary and launched a large credential stealer. Investigators found code for harvesting package-registry tokens, GitHub credentials, cloud keys, Kubernetes and Vault access, Stripe and Slack tokens, private keys, and database URLs.
The payload then used stolen npm tokens to publish malicious patch releases of every package the victim could maintain. GitHub tokens gave it a second route: it could modify repositories and add hooks to .claude/settings.json and .vscode/tasks.json, causing code to run when another developer opened the project.
The package count changed throughout the response. SafeDep confirmed 2,234 poisoned versions across 444 names and found that heavily downloaded transitive dependencies such as flat-cache and file-entry-cache carried the same payload.
Failure Point
root causeValid provenance proved that Keyv's real release pipeline built the package. It did not prove that the source entering that pipeline was safe. Once the install hook ran, npm gave it the developer account's readable files and inherited environment.
The worm needed two local capabilities to spread: permission to read credentials and permission to use them. Automic Vault controls that boundary on a Mac by removing supported credentials from ambient files and releasing them only to an approved command launched by an identified signed app.
Where Automic Vault Would Have Stopped It
preventionThe stealer would find fewer usable credentials
av scan finds exposed local credentials, while hardeners and av save move supported values into Keychain. Secrets removed from ~/.npmrc, ~/.config/gh, environment files, and cloud config are no longer readable by an npm install hook.
An install terminal would have no automatic handoff
Automic Vault checks the executable, signed launcher, command, working directory, and requested key before releasing a protected secret. Under the recommended policy, the terminal used for npm install gets no automatic secret access, so the worm cannot silently request those values.
Stolen-token propagation would fail
Without a protected npm publishing token or GitHub credential, the worm cannot publish under that developer's identity or commit hooks to their repositories. Other infected machines could still spread it, but this workstation would stop contributing credentials to the chain.
Workstation Prevention Boundary
local boundaryAutomic Vault would have prevented theft of credentials that a developer had moved behind its gate, provided the install ran from a launcher with no automatic access. Protecting npm and GitHub credentials would also have cut the worm's propagation route through that developer's packages and repositories.
The poisoned package could still install and execute arbitrary code. It could read plaintext secrets left outside Automic Vault, damage user-writable files, add persistence, and reach credentials supplied by cloud metadata or container service accounts. Automic Vault is a secret handoff boundary, not a general process sandbox.
Run package installs in a dedicated terminal with low-to-no privileges in both Automic Vault and macOS TCC. On a suspected host, follow the incident responders' order of operations and hunt the reported token monitor before rotating credentials, because investigators found a dead-man switch triggered by revocation.
Automic Vault does not clean an infected machine or make npm, GitHub Actions, Claude Code, or VS Code immune to compromise. It prevents protected secrets from becoming ambient authority. An approved executable can still use a secret released to it, and root compromise remains outside the product boundary.