Add an overrides entry to the root package.json naming the package and the fixed version, reinstall to update the lockfile, run the tests, and note a removal date. Overrides replace a package anywhere in the tree, but only the root project's package.json is read, and they can break things quietly.
When an agency needs this
A client app depends on library A, which depends on package B, which has a known vulnerability. A has not released a fix. You cannot edit B directly because it is not in your package.json. Waiting leaves the client exposed, and swapping out A may be a larger project.
What overrides do
The npm documentation says overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. It also says they are only considered in the root package.json for a project. That second point matters: an override inside a library you depend on has no effect on your build.
Steps
- Identify the path. Use the npm explain command on the vulnerable package to see who requires it.
- Choose the fixed version from the advisory. Prefer the smallest jump that fixes it.
- Add the override.
{
"overrides": {
"vulnerable-package": "2.3.5"
}
}
- Reinstall and review the lockfile diff. Check that only the expected package moved.
- Run the full test suite, and exercise the feature that uses the package manually if tests are thin.
- Re-run the audit and confirm the advisory is gone.
- Record the reason, advisory link, date and a review date in the repository, for example in a short DEPENDENCIES.md or the pull request.
- Tell the client what you did and why.
You can scope an override to apply only under a particular parent package, which limits the blast radius. Check the npm docs for the nested syntax.
Risks
- The parent library was tested against the old version. An override can introduce incompatibilities that only show at runtime.
- Overrides hide the problem. Dependency tools may stop warning, even though the parent is still outdated.
- They rot. A forgotten override can block a later upgrade or pin the project to an old version.
Remove it
Check each override at every dependency review. Remove it once the parent library ships a release that depends on a fixed version. If the parent is abandoned, plan a replacement, because an override is a patch and not a plan.
Alternatives
| Option | When it fits |
|---|---|
| Update the parent | A fixed release exists |
| Override | No fix upstream, low compatibility risk |
| Replace the parent | It is unmaintained |
| Accept with reasoning | The vulnerable code is not reachable in your use |
Reachability analysis helps with the last row: if your code never calls the vulnerable function, you may be able to record a decision rather than a patch.
Quick check
Do overrides work for Yarn and pnpm?
Each tool has its own mechanism with different names. This post covers npm only. Check your package manager's documentation.
Does an override fix the client's published bundle?
Only after you rebuild and redeploy. The change affects installs, not code already deployed.
Sources
Last reviewed: 19 October 2026.
