The Fix Is Too New: When Dependency Cooldowns Block Security Fixes
On December 3, 2025, the React team released a fix for a remote code execution flaw in React Server Components. The flaw is tracked as CVE-2025-55182 (GitHub CVSS 3.1: 10.0, critical). The advisory went public three and a half hours after the fixed versions were released. Within hours of that disclosure, AWS saw China-nexus threat groups trying to exploit it.
Now imagine the same day with today's default settings. Yarn and Deno refuse to install a release until it is at least a day old. A team on either one would have read the advisory and run the upgrade, and the package manager would have blocked the fixed version as too new. With a 7-day window, they would have waited a week. pnpm also waits a day by default, but it still installs the new version when no older one matches.
Nothing was misconfigured. The cooldown did what it was built to do.
Why is everyone cooling down?
Cooldowns are a response to malware published as ordinary package updates. In October 2026, version 0.5.144 of the tensorlake npm SDK was published with Shai-Hulud malware that steals GitHub secrets and cloud credentials. Anyone who installed it before it was pulled got the malware.
Malicious releases are usually caught fast. The pnpm docs say: "In most cases, malicious releases are discovered and removed from the registry within an hour." A short wait lets someone else find the problem first. That is why pnpm 11, Yarn and Deno all turned on a 1-day cooldown by default this year. Dependabot now waits three days before it proposes a version update.
Too new to install
A cooldown checks one thing: how long a version has been public. It cannot tell a release that adds malware from a release that removes a vulnerability.
Security fixes are almost always the newest release on the day you need them. In coordinated disclosure, the fix is released first and the advisory follows within hours or days.
Attackers move just as fast. VulnCheck found that 23.4% of known exploited vulnerabilities in the first half of 2026 were exploited on or before the day their CVE was published.
Add a policy that blocks versions affected by high or critical CVEs, and the team is stuck. The version in the lockfile fails the CVE rule, and the fix fails the cooldown. We described a team in that spot in Between a Rock and a Hard Place.
Does your tool let security fixes through?
A cooldown would be harmless if security fixes skipped it. We checked how each tool handles them.
Package managers
| Tool | Setting | Default window | Security fixes exempt? | When the only fix is too new |
|---|---|---|---|---|
| npm CLI | min-release-age |
Off | No, exclude list only | npm audit fix keeps the vulnerable version and exits with an error |
| pnpm | minimumReleaseAge |
1 day (since 11.0) |
Partly: pnpm audit --fix adds the fix to the exclude list |
Installs it (the default is non-strict); fails in strict mode or with a custom window |
| Yarn Berry | npmMinimalAgeGate |
1 day (since 4.15) |
No, exclude list only | Not documented |
| Bun | minimumReleaseAge |
Off | Partly: bun audit fix installs the fix even if it is newer than the window |
Not documented for regular installs |
| Deno | minimumDependencyAge |
1 day (since 2.9) |
No, exclude list only | Not documented |
| uv | exclude-newer |
Off | No, per-package opt-out only | Resolution fails; the error names the filter and the opt-out |
| pip | --uploaded-prior-to |
Off | No exclude list | Not documented |
| Poetry | solver.min-release-age |
Off | No, exclude by package or source | Not documented |
| Cargo | registry.global-min-publish-age |
Off (stable since Rust 1.100) |
No exclude list; a one-off override per command | Resolution fails |
| NuGet (accepted spec) | minPublishAgeHours |
Off | No: vulnerable packages wait like any other; exclude list only | Update picks the highest allowed version |
| Maven, Gradle, Go | None built in | Not applicable | Not applicable | Not applicable |
Update bots and registry gates
| Tool | Setting | Default window | Security fixes exempt? | When the only fix is too new |
|---|---|---|---|---|
| Renovate | minimumReleaseAge |
Off (presets suggest 3 days) | Yes, for its own security PRs | The PR opens, but the package manager can still block the lockfile update |
| Dependabot | cooldown |
3 days for version updates | Yes, and it turns off the npm, pnpm and Yarn cooldown on security PRs | Not affected |
| JFrog Curation | Immature version condition | Off (2, 14 or 30 days by level) | Opt-in: allow if the version fixes a CVE | Blocked |
| Socket | recentlyPublished |
Off | No, manual triage rules | Blocked when the policy action is error |
| StepSecurity | npm Package Cooldown check | 2 days | Partly: vendor suggests an admin override | PR check fails until the version is old enough |
Only the two update bots exempt security fixes, and only in their own pull requests. Dependabot also turns off the package manager's cooldown for those PRs. Renovate does not: the package manager still applies its cooldown to the lockfile update, so the PR can fail with an artifact error.
No package manager exempts a security fix by default, though the pnpm and Bun audit commands come close. Everywhere else, someone adds an exception by hand during the incident and has to remember to remove it later. In npm, the exclusion covers only the named package. If the fix also needs a new transitive dependency, that dependency is still blocked.
Keeping the cooldown and the fix
Turning the cooldown off brings back the risk it exists to stop. Adding exceptions one package at a time does not scale, and the number of fixes is growing. Anthropic reported more than 10,000 high- and critical-severity vulnerabilities found with a single model in about a month. Each of those vulnerabilities needs a fix, and each fix is a new release that a cooldown will delay.
The way out is to have the fix before the new release exists. Seal Security takes the security fix as soon as it is committed upstream, before the CVE is published and before a fixed version is released. We backport it into the exact version you already run. Our engineers review every backport and run the project's own tests before we publish it. When an advisory like React's appears, the patched version is already waiting in your registry. It passes both your cooldown and your CVE policy with no exceptions.
