A malicious package was installed

Poisoned packages steal whatever the machine can read: registry tokens, cloud keys, SSH keys and everything in the environment. The npm compromises of 2025 showed how fast that goes, with self-spreading malware that used stolen tokens to publish more poisoned packages. Assume every secret the install could read is gone.

Trigger. A registry advisory, a vendor alert or a dependency scanner says a package version you use was malicious, or a build or a developer laptop ran an install script it should not have.

The first 90 minutes2 of 5 expire

01 02 03 04 05

045 min90

01
Find every place the bad version was installed
by 20 minexpires
Lockfiles in every repository, build logs, container images and developer machines. The lockfile gives the version; the build log and the package manager cache give the time it was pulled, which opens your exposure window.
02
Rotate everything those machines could read
by 45 minexpires
Package registry tokens, source control tokens, cloud keys, CI secrets and SSH keys, starting with anything that can publish or deploy. Revoke the old ones rather than only issuing new ones.

Tell somebody

Every team that owns a repository with the package, today
Whoever owns CI and the registry accounts, on token rotation
Your own users, if you publish packages and a stolen token could have published one of yours

Drawn from

The documents these steps come from, so you can check one rather than take it on trust.

The evidence

What each source proves, and what it does not.

Collect it in one go

A read-only script that gathers most of the above in volatility order, with a hash manifest.

Triage collection

Make it yours

Replace the escalation list with real names, and the timings with what your change process actually allows. A playbook that assumes an authority you do not have will stall at the step that needed it.

Find every place the bad version was installed

Rotate everything those machines could read