When a dependency update goes wrong, return to the last known good lockfile, install strictly from it on a clean machine, rebuild, and redeploy. Then find out what the bad version did before you removed it. A revert of the manifest alone may not undo the resolved versions.
First decide: broken or malicious
A broken release causes errors. A malicious one may also have run code on your build machines and shipped to production. The first needs a rollback. The second needs a rollback plus credential rotation and a review of where it ran. If you cannot tell yet, handle it as the second until you know. The first day checklist for a compromised maintainer covers the exposure side.
The rebuild
1. Find the last good state. Look in version control for the last lockfile that produced a healthy release. The lockfile commit tied to the last good deploy is your target.
2. Restore it. Check out that lockfile and the matching manifest together. Restoring only one invites a mismatch.
3. Install strictly. For npm, npm ci is built for this. According to npm's documentation, it requires an existing lockfile, errors if the lockfile and package.json disagree instead of updating the lockfile, leaves package.json and lockfiles unchanged, and removes any existing node_modules before it starts. That clean slate matters if a bad package modified files.
4. Build on a clean environment. Use a fresh runner or container, not a developer machine with leftover state. If the bad version may have run install scripts there, the machine is suspect.
5. Compare. Diff the resulting dependency tree against the one in production. You should see the bad version gone and nothing else unexpected.
6. Test and deploy. Run your tests, then deploy with the smallest scope first if possible.
Stop it coming back
The same update will arrive again from an automated tool or a teammate. Prevent that:
- Pin the bad version out. Use your package manager's way to exclude or constrain it, and record why in a comment or ticket.
- Pause automated update pull requests for that package until you understand the fix.
- Make sure CI always installs strictly from the lockfile, so no job resolves fresh versions.
Check what shipped
List every environment that received a build with the bad version. A software bill of materials per release makes this a lookup. Without one, search build logs and images for the version string. Rebuild and redeploy each affected artifact.
If the version was malicious, rotate secrets that were reachable by any machine that installed it, starting with credentials that can publish or deploy.
Fix the process
Ask afterwards why a bad version got to production:
- Did a test suite miss it because no test covered the broken behavior?
- Did the update merge automatically without review?
- Was there a delay or canary stage before wide rollout?
- Did anyone check what changed in the update, including install scripts?
Add one control for each gap. A staged rollout that sends a small share of traffic to the new build first is one of the cheapest. See the rollback plan template and the guide on rolling back a bad dependency upgrade merge.
Use inventory to answer fast
Safeguard generates SBOMs and scans dependencies, which turns "where did that version go" into a query across repositories and releases. Policies and gates can block a named version from merging while you work. The demo below shows a dependency inventory.
Click through it at your own pace, or open it full screen.
Quick check
Is reverting package.json enough?
Not always. The lockfile records resolved versions, so restore the lockfile and manifest together and install strictly.
Why does npm ci delete node_modules?
It starts from a clean state so the result matches the lockfile exactly, which is what you want after a bad package.
Sources
Last reviewed: 19 October 2026.
