If a maintainer of a dependency you use has been compromised, first freeze updates to that package, then find out whether you installed any version published during the exposure window. If you did, treat the machines and pipelines that ran the install as exposed and rotate the secrets they could reach.
Hour 0 to 2: freeze and scope
Freeze means stop new versions from entering your builds. Pin the package to the last version you know was published before the incident, and make sure your install step uses the lockfile exactly. With npm, npm ci installs from the lockfile, removes any existing node_modules first, and stops with an error if the lockfile and package.json disagree, instead of rewriting the lockfile. That is the behavior you want during an incident.
Then scope. Search every repository, container image and deployed artifact for the package name and version. If you keep software bills of materials, this is a query. If you do not, it is a day of grep, which is a good argument for generating them.
Read the primary source before acting. Use the registry advisory or the maintainer's own statement, not a social media thread. Note which versions and which time range are named. If the advisory is unclear, say so in your incident notes and treat a wider range as suspect.
Hour 2 to 8: decide what was exposed
For each place you installed an affected version, ask three questions:
- Did install scripts or the package code run there? Build servers, developer laptops and CI runners all count.
- What secrets could that environment read? Think of environment variables, cloud credentials, registry tokens, SSH keys and files in the home directory.
- Did the build output ship? An affected version baked into a release may be running in production.
If the answer to the first question is yes, assume the secrets in the second were readable. The credential rotation playbook after an npm worm gives an order for rotation. Start with credentials that can publish or deploy.
Do not rely on the package having been removed from the registry. Removal stops new installs. It does not clean machines that already ran it. npm's own policy shows how deletion works: a version number that is unpublished can never be reused, and unpublishing cannot be undone, so a fixed version will carry a new number.
Hour 8 to 24: clean up and verify
- Rebuild affected artifacts from a clean state with the pinned, known good version.
- Redeploy anything that shipped an affected version.
- Review audit logs for use of rotated credentials before the rotation, such as unusual logins or new tokens.
- Watch for the maintainers' follow up: a fixed version, a deprecation notice, or a revoked token announcement.
- Record the timeline for the postmortem.
Decide on the long term
Ask whether you need this package at all. A tiny dependency with a single maintainer carries more risk than its size suggests. Options are to vendor it, replace it, or keep it with tighter controls such as a delay before adopting new versions.
Where tooling helps
Safeguard builds SBOMs and scans dependencies, so a question like "which of our services contain this version" becomes a lookup. Policies and gates can block a specific version from merging while you investigate. Reachability analysis helps prioritise afterwards, though for a malicious version assume execution on install and not only on call.
Click through it at your own pace, or open it full screen.
Quick check
The malicious version was removed from the registry. Are we safe?
Not necessarily. Removal stops new installs but does not clean machines that already installed and ran it. Check your lockfiles and build logs.
What is the first technical action?
Freeze dependency updates and install strictly from the lockfile, then search all repositories and artifacts for the affected versions.
Sources
Last reviewed: 19 October 2026.
