In JavaScript
Last updated: Aug 14, 2026
A transitive dependency (also called an indirect dependency) is a package that your project does not depend on directly, but that is required by one of your direct or intermediate dependencies.
The following strategies are listed in escalation order: try each one in sequence and move to the next only if the previous one does not resolve the issue.
Identify the dependency chain
Strategies 2 and 3 require knowing which direct or intermediate dependency pulls in the vulnerable package. Ask your package manager:
npm explain <package>Strategy 1: Update the transitive dependency
The first and simplest approach is to update the vulnerable dependency directly.
npm update <package>This works when the semver ranges specified by the direct or intermediate dependencies allow for the installation of a version that includes the security patch. However, if a direct or intermediate dependency pins the transitive dependencies to a specific vulnerable version or a range that excludes the patched release, this command will not update it.
Strategy 2: Update the direct or intermediate dependency
If the transitive dependency was not updated in the previous step, the direct or intermediate dependency is likely constraining its version. Update that dependency instead:
npm update <direct-or-intermediate-package>This may pull in a newer version of the transitive dependency that includes the security fix. Note that the direct dependency may already be at its latest version and still reference the vulnerable transitive package, in which case this strategy will also be insufficient.
Strategy 3: Use dependency overrides
When the semver ranges in the dependency tree prevent the installation of a patched version, you can force a specific version using overrides.
Add the following to your package.json:
"overrides": {
"<package>": "<safe-version>"
}Overrides bypass the version resolution logic of the package manager and may cause incompatibilities. Before merging, run all tests and linters locally and verify that the CI pipeline passes. If something breaks, move to strategy 4.
Strategy 4: Wait for an installable version
At this point the fix is out of your hands. There are two reasons a patched version may not be installable yet.
A release-age policy is holding the fix
Supply chain hardening often blocks packages published too recently.
In pnpm this is the minimumReleaseAge setting of pnpm-workspace.yaml;
other setups enforce it through a registry proxy or an organization policy.
When a patched version already exists but is younger than the threshold,
the fix lands on its own once the window elapses.
Do not lower the threshold, and do not reach for an override to jump over it. Both defeat the control that protects you from a release compromised minutes after being published.
The fix has not been released
The upstream project has not published a patched version yet. This involves two separate releases:
- The maintainers of the vulnerable package publish a patched version.
- The maintainers of the direct or intermediate dependency release a new version that adopts the patched transitive dependency.
This process can take days or longer. In the meantime, you may accept the risk through your vulnerability management workflow and track the upstream activity to act as soon as a safe version is available.
Additional strategy: Fork and remove shrinkwrap
In extreme cases,
a library may be shipped with an
npm-shrinkwrap.json
file that locks its dependency tree,
preventing overrides from taking effect.
In this scenario,
you can fork the library,
remove the shrinkwrap file,
and reference your fork until the upstream issue is resolved.
This approach requires the most effort and maintenance overhead,
so it should only be used when no other strategy is viable.
This applies to npm only. pnpm ignores npm-shrinkwrap.json and
package-lock.json entirely: it resolves from its own lockfile and does not
honor a shrinkwrap shipped by a dependency. The override of strategy 3 takes
effect regardless, so forking becomes unnecessary.