Treat it as a possible compromise of the machine or runner where the install ran. Disconnect or isolate it, find out whether install scripts executed, rotate any credentials that machine could read, remove the package, and then review how it got in. Act on the worst case until you rule it out.
Step 1: Contain
- If it ran on a laptop, disconnect it from the network and stop using sessions logged in on it for sensitive work until assessed.
- If it ran in CI, pause pipelines that share the runner and revoke the job's tokens.
- Do not delete evidence yet. Note the time, command and package version.
Step 2: Find out what ran
npm documents that preinstall, install and postinstall scripts run during install. Read the package's manifest and those scripts, in an isolated environment. Look for network calls, reads of environment variables, and file access outside the project.
If you cannot tell what it did, assume it read everything the user could.
Step 3: Rotate what was reachable
List credentials present on the machine or runner: cloud keys, registry tokens, SSH keys, API keys in environment variables, browser sessions. Rotate them in order of power, starting with anything that can deploy or access production.
Step 4: Remove and rebuild
- Remove the package from the manifest and lockfile.
- Delete the installed files and any cache.
- For a laptop that ran unknown code, consider a clean rebuild. For a CI runner, discard the instance.
- Check git for any commits or workflow edits made during the window.
Step 5: Look for spread
Search other repositories and images for the same package name. Check whether the lockfile was merged and other developers pulled it. Review logs at your cloud provider and registry for unusual activity after the install time.
Step 6: Report and learn
Report the package to the registry so it can be reviewed. Then ask what allowed it: no approval step for installs, no lockfile review, or an agent with too much freedom. Fix the control, not just the instance. See should AI coding agents run install commands.
Make the next one smaller
A frozen install from a reviewed lockfile, dependency review on pull requests and short lived credentials all shrink the blast radius. Safeguard's SBOM and dependency scanning can help you search for where a component is used.
Write it down while it is fresh
Keep a timeline as you go: when the install ran, what was found, which credentials were rotated and when. It helps the response, and it gives you material for the review afterward. If customers or regulators could be affected, involve your security lead and legal contact early, since notification duties depend on facts and jurisdiction that this post cannot assess.
Quick check
What if the package did not exist and the install just failed?
Then nothing ran, and no response is needed. Do not register the missing name yourself. Find the right library instead.
Sources
Last reviewed: 19 October 2026.