Back to Blog
high SEVERITY5 min read

How missing Dependabot cooldown happens in GitHub Actions and how to fix it

A Dependabot configuration file was missing a critical cooldown period, potentially exposing the project to malicious or unstable package updates immediately after publication. This high-severity issue was resolved by adding a 7-day cooldown period, giving the security community time to identify compromised packages before they're automatically proposed as updates.

O
By Orbis AppSec
Published July 21, 2026Reviewed July 21, 2026

Answer Summary

Missing Dependabot cooldown (CWE-829) occurs when `.github/dependabot.yml` lacks a `cooldown` block, allowing newly published (potentially malicious) packages to be immediately proposed as updates. The fix adds `cooldown: default-days: 7` to each package-ecosystem entry, creating a safety buffer that lets the community identify compromised packages before they reach your codebase.

Vulnerability at a Glance

cweCWE-829 (Inclusion of Functionality from Untrusted Control Sphere)
fixAdd `cooldown: default-days: 7` to each updates entry
riskAutomatic adoption of malicious or unstable package versions
languageYAML (GitHub Actions / Dependabot)
root causeNo cooldown block in dependabot.yml package-ecosystem configuration
vulnerabilityDependabot Missing Cooldown Period

Introduction

In the .github/dependabot.yml file of a Node.js library, we discovered a high-severity configuration gap at line 3. The Dependabot configuration was set to check for npm package updates daily, but it lacked a critical safety mechanism: the cooldown block.

Here's the vulnerable configuration that was in production:

version: 2
updates:
  - package-ecosystem: 'npm'
    directories:
      - '/'
    schedule:
      interval: 'daily'

This configuration tells Dependabot to propose updates as soon as new package versions are published—including packages that were uploaded just minutes ago. For a Node.js library with downstream consumers, this creates a significant supply chain risk.

The Vulnerability Explained

What Makes This Dangerous?

When a package maintainer's account is compromised, or when a malicious actor publishes a typosquatted package, the attack window is critical. Most supply chain attacks are discovered within the first few days of publication—but without a cooldown period, Dependabot could propose the malicious update before anyone notices.

Consider this attack timeline:

  1. Hour 0: Attacker compromises an npm package maintainer's credentials
  2. Hour 1: Attacker publishes version 2.1.0 with a backdoor
  3. Hour 2: Your Dependabot runs its daily check and creates a PR to update to 2.1.0
  4. Hour 3: A developer merges the PR, trusting the automated update
  5. Hour 24: Security researchers discover and report the compromise
  6. Hour 48: npm removes the malicious version

Without a cooldown, your project adopted the malicious package 46 hours before it was even flagged.

Real-World Impact for This Library

This isn't just theoretical. The vulnerable configuration was for a Node.js library—meaning any malicious dependency automatically proposed by Dependabot would propagate to every downstream consumer who installs or updates this package. The blast radius extends far beyond a single repository.

The npm ecosystem has seen numerous supply chain attacks:
- event-stream (2018): Compromised after ownership transfer
- ua-parser-js (2021): Hijacked maintainer account
- node-ipc (2022): Malicious code added by maintainer

In each case, there was a window of hours to days before the community identified the threat. A 7-day cooldown would have prevented automatic adoption in all these incidents.

The Fix

The fix adds exactly two lines to the Dependabot configuration:

Before (Vulnerable)

version: 2
updates:
  - package-ecosystem: 'npm'
    directories:
      - '/'
    schedule:
      interval: 'daily'

After (Secure)

version: 2
updates:
  - package-ecosystem: 'npm'
    directories:
      - '/'
    schedule:
      interval: 'daily'
    cooldown:
      default-days: 7

How This Solves the Problem

The cooldown block with default-days: 7 instructs Dependabot to wait 7 days after a package version is published before proposing it as an update. This creates a safety buffer that:

  1. Allows community vetting: Security researchers, automated scanners, and the broader community have time to analyze new releases
  2. Catches compromised packages: Most supply chain attacks are detected within 72 hours of publication
  3. Filters unstable releases: Packages with critical bugs are often patched quickly; waiting 7 days means you're more likely to get a stable version
  4. Maintains automation benefits: You still get automated dependency updates—just with a sensible delay

The change is minimal (2 lines) but the security improvement is substantial.

Prevention & Best Practices

Always Configure Cooldown Periods

For any Dependabot configuration, add a cooldown block to every package-ecosystem entry:

cooldown:
  default-days: 7

For critical production systems, consider extending this to 14 or even 30 days.

Audit Your Existing Configurations

Search your organization's repositories for Dependabot configurations missing cooldown:

# Find all dependabot.yml files
find . -name "dependabot.yml" -exec grep -L "cooldown" {} \;

Use Semgrep for Automated Detection

The Semgrep rule package_managers.dependabot.dependabot-missing-cooldown.dependabot-missing-cooldown automatically detects this misconfiguration. Add it to your CI pipeline:

- name: Semgrep scan
  run: semgrep --config "p/security-audit" .

Layer Your Defenses

Cooldown is one layer in a defense-in-depth strategy:
- Lock files: Always commit package-lock.json or yarn.lock
- Dependency review: Require manual review for dependency PRs
- SCA tools: Use Software Composition Analysis to scan for known vulnerabilities
- Subresource integrity: For CDN-loaded dependencies, use integrity hashes

Key Takeaways

  • The missing cooldown block in .github/dependabot.yml created a 0-day adoption window for potentially malicious npm packages
  • A 7-day cooldown period aligns with typical supply chain attack detection timelines
  • Node.js libraries have amplified risk because vulnerabilities propagate to all downstream consumers
  • This 2-line YAML change provides significant protection against supply chain attacks with zero impact on developer workflow
  • Semgrep rule dependabot-missing-cooldown can detect this configuration gap automatically

How Orbis AppSec Detected This

  • Source: Newly published npm package versions from the public registry
  • Sink: Automatic PR creation by Dependabot in .github/dependabot.yml:3
  • Missing control: No cooldown block to delay adoption of new package versions
  • CWE: CWE-829 (Inclusion of Functionality from Untrusted Control Sphere)
  • Fix: Added cooldown: default-days: 7 to the npm package-ecosystem entry, creating a 7-day buffer before new versions are proposed

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

Supply chain security isn't just about scanning for known CVEs—it's about building resilient configurations that protect against zero-day attacks. The missing Dependabot cooldown in this Node.js library represented a high-severity gap that could have allowed malicious packages to flow automatically into the codebase and, subsequently, to all downstream consumers.

The fix was simple: two lines of YAML. But the protection it provides is substantial. If you're using Dependabot, audit your configurations today and ensure every package-ecosystem entry includes a cooldown period. Your downstream users are counting on it.

References

Frequently Asked Questions

What is a Dependabot missing cooldown vulnerability?

It's a configuration weakness where Dependabot proposes package updates immediately after publication, before the security community can identify if the new version contains malicious code or critical bugs.

How do you prevent missing cooldown in Dependabot?

Add a `cooldown` block with `default-days: 7` (or more) to each `package-ecosystem` entry in your `.github/dependabot.yml` file.

What CWE is Dependabot missing cooldown?

CWE-829: Inclusion of Functionality from Untrusted Control Sphere, as it relates to automatically incorporating external code without adequate verification time.

Is daily update scheduling enough to prevent malicious package adoption?

No, daily scheduling only controls when Dependabot checks for updates—it doesn't prevent immediate adoption of newly published malicious packages. A cooldown period is required.

Can static analysis detect missing Dependabot cooldown?

Yes, tools like Semgrep can scan YAML configuration files and flag missing cooldown blocks in Dependabot configurations.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #29733

Related Articles

high

How NO_PROXY bypass via crafted URL happens in Node.js axios and how to fix it

A high-severity vulnerability (CVE-2026-42043) in axios versions prior to 1.15.1 allowed attackers to bypass NO_PROXY environment variable restrictions using specially crafted URLs. This meant HTTP requests intended to stay internal could be routed through an attacker-controlled proxy, potentially exposing sensitive data. The fix upgrades axios to version 1.15.1, which correctly validates URLs against NO_PROXY rules.

critical

How JSON request validation bypass happens in Node.js API handlers and how to fix it

A critical validation bypass in the `/api/agents/jobs` endpoint allowed attackers to send malformed JSON with arbitrary properties that could trigger prototype pollution or unexpected behavior. The fix added comprehensive validation checks including array detection and property existence verification to prevent malicious payloads from reaching downstream processing logic.

critical

How Server-Side Request Forgery happens in Node.js httpProxy.js and how to fix it

A critical Server-Side Request Forgery (SSRF) vulnerability was discovered in `hubcmdui/routes/httpProxy.js` where the `/proxy/test` endpoint passed a user-controlled `testUrl` parameter directly to `axios.get()` without any validation. An attacker could exploit this to probe internal infrastructure — including AWS metadata endpoints, Redis instances, and private network ranges. The fix introduces a strict URL validation function that blocks private IP ranges, loopback addresses, and non-HTTP(S)

critical

How Remote Configuration Injection happens in JavaScript fetch() and how to fix it

A critical vulnerability in `js/config.js` allowed attackers to inject malicious configuration data through DNS spoofing or man-in-the-middle attacks. The application fetched remote JSON configuration from GitHub without validating the response structure, enabling arbitrary code execution through crafted payloads. A single validation check now ensures only properly-formed configuration objects are accepted.

high

How missing Dependabot cooldown configuration happens in GitHub Actions and how to fix it

A high-severity vulnerability was discovered in the `.github/dependabot.yml` configuration file where no cooldown period was set for dependency updates. This exposed the Node.js library and its downstream consumers to potentially malicious or unstable packages immediately after publication. The fix adds a 7-day cooldown period to all package ecosystem entries, providing a critical safety buffer before accepting newly published package versions.

high

How command injection happens in Ruby backticks and how to fix it

A Jekyll plugin used unsafe Ruby backticks to execute a `git log` command with an unescaped file path, creating a command injection vulnerability. By switching to `Open3.capture2()` with argument array syntax, the fix prevents shell interpretation and eliminates the attack surface entirely.