Supply chain · npm ·

npm min-release-age: allow one urgent security patch

You set a release-age window so a freshly published, possibly compromised version is less likely to land in your tree. Then a security advisory drops, the fixed version is two days old, and npm audit fix won't install it. This post shows how to let that one fix through without switching the window off for everything.

If you want the next step, read Supabase service role key exposed? How to check, rotate, and stop it happening again.

Quick fix

npm (.npmrc): add a temporary exemption for the one package, install, then remove the line.

min-release-age = 7
min-release-age-exclude[] = the-vulnerable-pkg

pnpm (pnpm-workspace.yaml, pnpm 10.19 or later): exempt only the exact patched version.

minimumReleaseAge: 10080
minimumReleaseAgeExclude:
  - the-vulnerable-pkg@4.2.1

Dependabot: you usually don't need to do anything. Cooldown applies to version updates only, never to security updates.

The rest of this post explains why each of these works and what to watch.

Why npm audit fix is blocked

npm's min-release-age (added in npm 11.10.0) takes a number of days. It's off by default (null). When set, npm only installs versions that were published more than that many days ago, and if no version fits your dependency ranges, the command errors.

The npm docs say that when the window stops npm audit fix from installing a patched version, npm keeps the package at its vulnerable version, warns that the fix was blocked, and exits with a non-zero code (npm 11.18.0 and later; earlier versions skip the fix silently). So in CI, the step fails, and locally, the vulnerable version stays.

There's a related setting, before, which takes an absolute date. If both are set in the same source, before wins. Across sources the usual precedence applies (command line, then environment, then project, then user, then global), so a higher-priority source can relax a lower-priority one.

npm: exempt one package with min-release-age-exclude

min-release-age-exclude is a list of package names or minimatch globs that skip the min-release-age (and before) filter. It was backported to npm v11 in June 2026 (npm/cli#9534), and shipped in npm 11.17.0, so you need 11.17.0 or later.

# .npmrc
min-release-age = 7
# TEMP: GHSA-xxxx-xxxx-xxxx, remove after the fix ages past the window
min-release-age-exclude[] = the-vulnerable-pkg

Then pin the fixed version explicitly instead of relying on "newest":

npm install the-vulnerable-pkg@4.2.1

Three things to know, all from the npm docs:

  • It matches names, not versions. While the line is there, the package can resolve to its newest release, including one published after the fix. Pin the exact version and remove the line once the fix is older than your window.
  • Only the named package is exempt. Its own dependencies still follow the release-age policy unless they also match a pattern. If the patch pulls in a brand-new transitive dependency, you may need to exempt that too.
  • It doesn't change the registry. An excluded package is fetched from the same registry as before.

pnpm: exempt one exact version with minimumReleaseAgeExclude

pnpm's minimumReleaseAge lives in pnpm-workspace.yaml and is in minutes, not days. It was added in pnpm 10.16.0. The default is 1440 (one day) since pnpm 11, and 0 before that. It applies to transitive dependencies too.

minimumReleaseAgeExclude takes package names (10.16), patterns such as '@myorg/*' (10.17), and since 10.19 exact versions, which is what you want for a security patch:

# pnpm-workspace.yaml
minimumReleaseAge: 10080   # 7 days, in minutes
minimumReleaseAgeExclude:
  - the-vulnerable-pkg@4.2.1
  # several versions: - webpack@4.47.0 || 5.102.1

A version exemption only lets that exact version through, so it's the narrower option. With pnpm 11.22 or later, minimumReleaseAgeExcludePrune: true drops exclude entries the new lockfile no longer resolves. Name patterns are always kept.

Two pnpm 11 settings change what "blocked" looks like:

  • minimumReleaseAgeStrict defaults to true if you set minimumReleaseAge yourself, and false if you're relying on the built-in 1440. When it's false, pnpm falls back to a too-new version so the install still succeeds. When it's true, resolution fails instead.
  • minimumReleaseAgeIgnoreMissingTime defaults to true, so packages from a registry that doesn't publish the time field skip the check. Set it to false to fail instead.

Dependabot: cooldown never blocks security updates

Dependabot's cooldown goes under each updates entry in .github/dependabot.yml. GitHub's docs say it applies to version updates only, and that a default cooldown of 3 days applies to version updates even when you don't configure one. Security updates aren't delayed.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
      semver-major-days: 30
      semver-patch-days: 3
      exclude:
        - "the-vulnerable-pkg"

include and exclude take up to 150 items each and support * wildcards. If a dependency is in both lists, exclude wins and it updates immediately. You only need exclude if you want a normal version update to skip the cooldown.

The catch: Dependabot opening a security PR doesn't mean your install will accept it. If your repo also sets npm min-release-age or pnpm minimumReleaseAge, CI can still fail on that PR until you add the exemption above.

Keep exemptions temporary

A cautious routine for one urgent patch:

  1. Confirm the advisory and the exact fixed version.
  2. Add one exemption, ideally an exact version (pnpm) or a name plus a pinned install (npm), with a comment naming the advisory.
  3. Install, commit the lockfile, and run your tests.
  4. Remove the exemption once the fix is older than your window.

The release-age window is designed to reduce the chance of installing a just-published bad release. It doesn't detect malware, and each exemption is a hole in it, so keep them few and short-lived.

FAQ

Is it min-release-age or minimum-release-age in npm? The documented npm key is min-release-age, with min-release-age-exclude for exemptions.

What unit does each tool use? npm min-release-age and Dependabot cooldown use days. pnpm minimumReleaseAge uses minutes, so 7 days is 10080.

Can npm exempt a single version instead of a whole package? The npm docs describe package names and glob patterns only. Pin the version in your install command and remove the exemption afterwards.

Why did pnpm 11 start delaying installs I never configured? minimumReleaseAge defaults to 1440 minutes since pnpm 11. Because you didn't set it, strict mode is off, so pnpm falls back to a newer version rather than failing.

Does Dependabot cooldown delay security updates? No. GitHub's docs say cooldown applies only to version updates.

Sources

Checked against those docs on 24 Oct 2026. We haven't run these configs against a live registry.

npm is a trademark of npm, Inc. GitHub and Dependabot are trademarks of GitHub, Inc. pnpm, webpack and other names belong to their owners. Names are used only to identify products and compatibility. Stack & Ship is not affiliated with or endorsed by any of them.

Related posts