Safeguard
Developer Tools•

Why npm overrides in my library do not fix my users' vulnerability

npm overrides only apply in the root package.json, so a library cannot use them to patch a dependency for users. What to do instead, step by step.

Safeguard Security Team
4 min read

An overrides entry in your library's package.json does nothing for people who install your library. The npm docs say overrides are only considered in the root package.json of a project, and overrides in installed packages are ignored. To protect users, raise your dependency range.

What overrides are for

The npm documentation describes overrides as a way to change dependencies of your dependencies, such as forcing a patched version or swapping in a fork. For example, you can pin foo to a version everywhere in the tree.

That is a tool for the owner of an application. If you run a web app and a transitive package has an advisory, an override in your app's package.json can force the patched version while you wait for the middle package to update.

Why it fails for a library

Your library is not the root when someone installs it. Their project is the root. The npm page is explicit: "Overrides are only considered in the root package.json file for a project." So your override works in your own repository during development and CI, which can make it look like a fix, but it disappears from the tree of anyone who depends on you.

This is a common trap. Tests pass, the scanner on your repository goes quiet, and users still resolve the vulnerable version.

What to do in a library

  1. Find the chain. Which of your direct dependencies pulls in the vulnerable package?
  2. Check for a fixed release of that direct dependency. If one exists, raise your range to it, and the vulnerable transitive version leaves your users' trees at the next install.
  3. If none exists, ask upstream. Open an issue or pull request against the middle package asking for a bump.
  4. If your code does not reach the flaw, say so. A short note in your security policy or an advisory comment can save users from filing reports (see the related post on advisories for vulnerable dependencies).
  5. As a last resort, replace or vendor the dependency. This has maintenance costs, so decide on purpose.

Keep the override for yourself

You can still use an override in your own repository so your CI tree is clean while you wait. Leave a comment explaining it, link the upstream issue, and remove it once upstream ships:

{
  "overrides": {
    "vulnerable-package": "2.3.1"
  }
}

Note in the release notes that the fix is local, so users know to add their own override if they are affected.

Tell users what to do

Users who are affected can add the override in their own root package.json. A line in your README or release notes with the package name and safe version helps them. Phrase it as a temporary workaround.

Apps versus libraries at a glance

ApplicationLibrary
Does overrides take effectYes, it is the rootOnly in your own repo
Best fixOverride or upgradeRaise the range on the direct dependency
Who is protectedYouYour users, once ranges move

Quick check

Can I ship a library with overrides so users get the patched version?

No. npm ignores overrides in installed packages.

Is an override useful in my library's repository at all?

Yes, as a temporary measure for your own CI and development tree. Document it and remove it when upstream is fixed.

Safeguard's dependency scanning shows which direct dependency brings in a vulnerable transitive package, which is the first step above. Try the free scan.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.