After a package compromise, choose the last version published before the incident window, confirm it against the maintainer or registry advisory, then check its contents before you pin it. Do not jump to the newest version just because it is newest, since an attacker may also publish follow up releases.
Why not simply update
During an incident, new releases arrive fast: the attacker's, the maintainer's emergency fix and sometimes copycats. The highest number is not always the cleanest. A pinned version you have verified is safer than a fresh one nobody has reviewed.
Decision guide
| Option | When to use | Risk |
|---|---|---|
| Last version before the window | Default choice | May lack unrelated fixes |
| Maintainer's clean new version | Advisory names it explicitly | Verify it came from the maintainer |
| Remove the dependency | Package is abandoned or trivial | Needs code change |
| Fork or vendor a copy | No trusted release exists | You own maintenance |
Steps
- Get the compromised version list and times from the registry advisory or maintainer.
- Take the last release before the first bad one, and check its publish date.
- Compare its file listing and install scripts against the version before it. Unexpected new files or scripts are a warning sign.
- If the package is a transitive dependency, pin it with an override in the root package.json. The npm documentation describes overrides as replacing a package in the tree with another version.
- Reinstall from the lockfile with a command that does not change it, such as npm ci. That command exits with an error if the lockfile and package.json disagree.
- Wait for a cooling period before accepting new releases of that package. See dependency cooldown periods.
- Record the version you chose and why.
Watch for
Fake fix announcements pointing to a new package name, and messages telling you to run a one line install. Take fix instructions from the registry advisory or the maintainer's official repository only.
For rollback steps see how to roll back a bad dependency upgrade.
Record the decision
Write a short note in the incident log: package, versions removed, version chosen, evidence used to choose it, who approved. Add a comment next to any override in the manifest saying why it exists and when it can be removed. Overrides added in a hurry tend to stay for years and hide later fixes. Set a reminder to review each one after the maintainers publish a verified fix.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a fixed version is shown next to the vulnerable one, and compare it with the checks above.
Quick check
Is the newest version the safest?
Not necessarily. Prefer a version you have verified over the most recent one.
What if the package has no clean version?
Remove it, vendor a reviewed copy, or replace it with an alternative.
Safeguard's dependency scanning shows fixed versions where known, and its autonomous remediation can open fix pull requests, off by default. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
