On July 14, 2026, GitHub enabled a default three-day cooldown on Dependabot version updates. When a new release appears on a package registry, Dependabot now waits at least three days before opening a version update PR. The goal is to give the community time to discover and flag compromised or broken releases before they reach your lockfile through automated updates.
The default costs almost nothing (a three-day delay on non-security updates) and blocks a real attack pattern: publishing a malicious version and relying on automated tooling to distribute it before anyone notices. The coverage still has clear boundaries.
What changed
Before this update, Dependabot opened version update PRs as soon as it detected a new release during its scheduled run. A malicious package version published at 2 AM could have a PR waiting for a maintainer by 6 AM.
The new default inserts a three-day gap. Dependabot still checks for updates on its configured schedule (daily, weekly, or monthly), but it skips any version that has been on the registry for fewer than three days. No configuration is required. The default applies to all supported ecosystems on github.com and will ship in GitHub Enterprise Server 3.23.
Security updates are exempt. When a GitHub Advisory flags a vulnerability and a patched version exists, Dependabot opens that PR immediately regardless of how recently the fix was published. The cooldown applies only to routine version bumps.
Configuring the cooldown
The default works without any changes to dependabot.yml. To customize it, add a cooldown block to an update entry:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
cooldown:
default-days: 5
semver-major-days: 7
semver-minor-days: 4
semver-patch-days: 2Available parameters
| Parameter | What it controls |
|---|---|
default-days | Cooldown for dependencies without a more specific rule |
semver-major-days | Cooldown for major version bumps (e.g. 2.0.0 to 3.0.0) |
semver-minor-days | Cooldown for minor version bumps (e.g. 2.1.0 to 2.2.0) |
semver-patch-days | Cooldown for patch version bumps (e.g. 2.1.0 to 2.1.1) |
include | Dependencies to apply cooldown to (up to 150, supports * wildcards) |
exclude | Dependencies exempt from cooldown (up to 150, supports * wildcards) |
The exclude list always wins. If a dependency appears in both include and exclude, it is excluded from cooldown and updated immediately.
SemVer parameter support
Not every ecosystem supports SemVer-specific cooldowns. All ecosystems support default-days. The SemVer-level parameters (semver-major-days, semver-minor-days, semver-patch-days) are supported by npm/Yarn, Cargo, pip, Composer, Maven, NuGet, Bundler, Go modules, Gradle, Swift, Pub, and others that use semantic versioning natively. Ecosystems like Docker, GitHub Actions, Terraform, and Helm support only default-days.
Opting out
To disable cooldown entirely for an ecosystem:
cooldown:
default-days: 0This restores the previous behavior where Dependabot opens PRs as soon as it detects a new version.
What the cooldown disrupts
The three-day window targets a specific phase of supply chain attacks: the period between a malicious version being published and the community detecting it.
Rapid-fire version publishing. The jscrambler compromise saw five malicious versions published in three hours, with the attacker adapting mid-attack. A three-day cooldown would have prevented all five versions from reaching automated PRs before the community response was underway. The first detection came within hours, the maintainer remediation within minutes after that. By day three, the malicious versions were deprecated.
Smash-and-grab account compromise. When an attacker gains access to a maintainer’s publishing token and pushes a single malicious version, the window between publication and detection is the critical variable. Community detection through download monitoring, automated scanning, or user reports typically surfaces compromises within 24 to 72 hours. A three-day cooldown sits right at the edge of that detection window.
Dependency confusion with new packages. If an attacker publishes a new package to a public registry that shadows a private package name, the three-day delay gives security teams more time to notice the unexpected new package before it appears in automated PRs.
What the cooldown does not cover
Security updates bypass the cooldown
The exemption is deliberate: when a known vulnerability has a fix, speed matters more than caution. It does mean an attacker who can get a GitHub Advisory created for a fake vulnerability in their own package could use the security update path to skip the cooldown. Creating a convincing advisory for a package with real users takes real effort, and the exemption still exists.
Malicious versions that survive three days
The cooldown assumes malicious versions get caught within three days. Some do not. The ai-pro-sdk campaign uses encrypted, obfuscated payloads that do not trigger simple static analysis. Packages with low download counts receive less community scrutiny. If a malicious version is still live on day four, the cooldown provides no further protection. Dependabot opens the PR as if nothing is wrong.
Install-time attacks outside Dependabot
The cooldown applies to Dependabot version update PRs. It does not affect:
- Manual
npm install package@latestcommands - CI pipelines that resolve floating version ranges on every build
- Lock-free installations where the latest version is always pulled
- Other update tools (Renovate, custom scripts) unless they implement their own cooldown
Developers who install packages directly are not protected by this change.
Existing dependencies at current versions
Cooldown applies to new version updates. If your lockfile already pins a malicious version, the cooldown does nothing. It prevents Dependabot from moving you to a bad version, not from staying on one.
Tag-based ecosystems
For ecosystems like GitHub Actions and Docker, where versions are tags rather than immutable registry artifacts, the concept of “available on its registry for three days” is less clear-cut. A GitHub Action tag can be force-pushed to point at different code without publishing a new version. The cooldown counts from when the version appeared, not from when the underlying code changed. SHA pinning remains the primary defense for these ecosystems.
Transitive dependencies
Dependabot version updates target your direct dependencies. If a transitive dependency (a dependency of your dependency) publishes a malicious version, the cooldown does not apply unless your direct dependency also publishes a new version that pulls it in.
What to do now
Leave the default on. Three days is a reasonable delay for version updates. If your project can tolerate a slightly longer buffer, consider raising default-days to 5 or 7. The cost is minimal for most projects.
Use SemVer-specific days for fine-grained control. Major version bumps deserve more scrutiny and a longer cooldown. Patch updates from trusted, high-traffic packages can safely use a shorter window:
cooldown:
semver-major-days: 7
semver-minor-days: 4
semver-patch-days: 2Do not disable cooldown for convenience. Setting default-days: 0 restores the old behavior where a malicious version can reach a PR within hours. The three-day delay is not a bottleneck for any reasonable development workflow.
Pair cooldown with lockfile discipline. Cooldown protects the update path, not the install path. Pin exact versions in your lockfile (npm ci, not npm install). Use --ignore-scripts or npm v12’s allowScripts default to block install-time execution. Cooldown and lockfile pinning cover different attack surfaces.
Keep watching transitive dependencies. Cooldown covers your direct dependencies in Dependabot PRs. Your transitive dependency tree is not covered. Use npm audit, npm sbom, or a dedicated SCA tool to monitor the full graph.
Remember that SHA pinning is still necessary for GitHub Actions. The cooldown applies to GitHub Actions version updates via default-days, but the underlying problem with Actions is tag mutability, not release timing. Pin to full commit SHAs and use Dependabot or Renovate to keep the SHAs current. The cooldown adds a small buffer on top, but SHA pinning is the primary control.
Where Aephix fits
The cooldown buys time. Three days for the community to notice that a package version is compromised. The question is what happens during those three days, and what happens when three days is not enough. Some malicious packages survive for weeks or months because they use encrypted payloads, low download counts, or target niche ecosystems where fewer eyes are watching.
Aephix Sleuth links a flagged package to the wider operation behind it, with a confidence level and supporting evidence, across packages, models, skills, MCP servers, extensions, and containers. When Dependabot proposes an update, the version age is only part of the picture. Who published it, and what else have they published, matters more. Aephix Vantage gives you a free, cross-ecosystem view of what is already known to be malicious, so a package that the cooldown let through is something you can still catch before it merges.