The npm attack that turned provenance attestations into camouflage
Security researchers this week disclosed an npm supply-chain attack affecting more than 400 packages, including projects connected to Keyv and Cacheable. The attackers used stolen developer credentials to publish malicious versions.
This incident appears to point to a trend in software security: Attackers are going after the developers and workflows already trusted to publish.
Attackers are going after the developers and workflows already trusted to publish.
Worm spreads through credentials
According to Microsoft Threat Intelligence, the malicious releases contained a variant of the Mini Shai-Hulud credential-stealing worm as they bypassed source repositories as they spread, and began with stolen maintainer credentials. Once inside, the worm searched developer machines and CI environments for any other credentials it could use.
When it found an active npm publishing token, it downloaded the latest version of every package the account could access, injected a malicious preinstall lifecycle hook, bumped the patch number and published the infected versions. Because npm runs preinstall hooks automatically before installation finishes, the malware could start running on developer workstations and CI runners before application tests or security checks began.
Because npm runs preinstall hooks automatically before installation finishes, the malware could start running on developer workstations and CI runners before application tests or security checks began.
Preinstall hooks enable silent execution
In CI environments, it stayed connected to the active job, where it could reach workflow secrets, runner credentials, and publishing permissions. On workstations, it could continue running in the background and inject startup files into Visual Studio Code and Claude, including .vscode/tasks.json and .claude/settings.json.
The attack exposed a weakness in trusted publishing, highlighting that malware running inside an authorized workflow can request its own short-lived token instead of stealing a long-lived publishing credential. The resulting malicious package can even carry valid provenance attestations.
Provenance doesn’t guarantee integrity
This campaign shows how quickly an attack can move from a developer’s machine into the rest of the release process.
Isolate publishing from dependency installation
Microsoft recommends upgrading to npm CLI 12, pinning known-good versions and using min-release-age to give teams time to review new releases before they are installed.
Rotating the stolen token may not be enough once a compromised package has run its lifecycle scripts. Teams may also need to rebuild affected machines and base images, clear shared caches and recreate software artifacts from trusted dependencies.
