How do you force a safe version of a transitive npm or Yarn dependency?

Use the overrides field in package.json for npm or the resolutions field for Yarn to force a specific version of a nested package when its parent has not released a fix. Scope the override as tightly as you can, test it, and remove it once the parent updates.

The problem

Your project depends on package A, and A depends on package B at a version with a known vulnerability. You cannot edit A's manifest, and waiting for a new release of A may take a while. Pinning in your own direct dependencies does not help, because B is not one of them.

npm overrides

The npm documentation says the overrides field lets you make sure a package is always installed at one version no matter what your dependencies rely on. The short form applies everywhere:

{
  "overrides": {
    "foo": "1.0.0"
  }
}

The documentation also shows narrower forms. To override foo only when it is a descendant of bar, nest the key under bar. Keys can nest to any length, and a key can include a version or range, so an override can apply only when the parent is a specific release, written like bar@2.0.0.

{
  "overrides": {
    "bar@2.0.0": {
      "foo": "1.0.0"
    }
  }
}

One rule to know: you may not set an override for a package you depend on directly unless the dependency and the override share the exact same spec.

Yarn resolutions

Yarn's manifest documentation says the resolutions field overrides the resolutions of specific dependencies, instructing Yarn to use a specific version instead of whatever the resolver would pick. It is useful, the page says, to enforce that all your packages use a single version of a dependency, or to backport a fix. The field can only be set at the project root and warns if used in another workspace.

{
  "resolutions": {
    "relay-compiler": "3.0.0"
  }
}

The same documentation shows scoped keys that target a package under a parent.

A safe procedure

1. Confirm which versions are fixed. Read the advisory, and do not guess a version.
2. Add the narrowest override that covers the vulnerable path.
3. Reinstall and regenerate the lockfile. Check that the nested package now resolves to the fixed version.
4. Run your tests. A forced version is a version the parent was not tested with.
5. Leave a comment or ticket reference explaining why the override exists and when to remove it.
6. Remove it when the parent releases an update that includes the fix. Stale overrides quietly hold you on a version nobody reviews.

Risks

An override changes the dependency graph beyond what the maintainers tested. A patch release is usually safe, and a major jump may not be. If the parent calls APIs that the new version removed, you can swap a vulnerability for a runtime bug.

Overrides are also easy to forget. Each one is a small fork of your dependency policy, so list them in review and revisit them on a regular schedule.

Does the code even call it

Before rushing, check whether the vulnerable function is reachable from your code. Reachability does not remove the finding, but it helps you decide whether this is an emergency or the next scheduled update.

Where Safeguard fits

Safeguard's reachability analysis helps show whether a vulnerable function in a transitive package is actually reachable, and autonomous remediation can open fix pull requests. It is off by default, with every category on Manual. A free scan is available at gold.safeguard.sh/scan.

Try it yourself

Open the demo and compare all findings with the reachable ones, then decide which override would be urgent.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• npm Docs: package.json (overrides)
• Yarn: Manifest (resolutions)

Last reviewed: 19 October 2026.