In JavaScript

Last updated: Sep 30, 2026

Try the strategies below in this sequence. Move to the next strategy only if the previous one does not correct the problem.

Identify the dependency chain

For strategies 2 and 3, find the direct or intermediate dependency that pulls in the vulnerable package. Use your package manager:

npm explain <package>

Strategy 1: Update the transitive dependency

The first and simplest method is to update the vulnerable dependency directly.

npm update <package>

This works when the semver ranges of the direct or intermediate dependencies let you install a version with the security patch. But a direct or intermediate dependency can pin the transitive dependency to a vulnerable version, or to a range that excludes the patched release. If it does, this command does not update it.

Strategy 2: Update the direct or intermediate dependency

If strategy 1 did not update the transitive dependency, a direct or intermediate dependency probably constrains its version. Update that dependency:

npm update <direct-or-intermediate-package>

This can pull in a newer version of the transitive dependency with the security fix. But the direct dependency can be at its latest version and continue to use the vulnerable transitive package. If it does, this strategy also does not correct the problem.

Strategy 3: Use dependency overrides

When the semver ranges in the dependency tree block the patched version, force a safe version with an override.

"overrides": {
  "<package>": "<safe-version>"
}

Strategy 4: Wait for an installable version

At this point, the fix is out of your hands. Two causes can prevent the installation of a patched version.

A release-age policy holds the fix

Supply chain hardening frequently 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 exists but is younger than the threshold, the fix lands on its own after the window.

Do not lower the threshold. Do not use an override to remove the wait. These two actions defeat the control that protects you from a release compromised minutes after its publication.

Upstream has no patched version

The upstream project did not publish a patched version. Two releases are necessary:

1. The maintainers of the vulnerable package publish a patched version.
2. The maintainers of the direct or intermediate dependency release a new version that adopts the patched transitive dependency.

This procedure can continue for days or longer. In the meantime, you can accept the risk through your vulnerability management workflow. Monitor the upstream project. Update when a safe version is available.

One more strategy: Fork and remove shrinkwrap

Sometimes, a library ships with an npm-shrinkwrap.json file. This file locks its dependency tree, and overrides have no effect.

To correct this problem, fork the library. Remove the shrinkwrap file. Then point to your fork until upstream corrects the problem. This method has the highest cost in work and maintenance. Use it only when no other strategy works.