Back to Blog
high SEVERITY5 min read

How Missing Dependabot Cooldown happens in GitHub Actions and how to fix it

A high-severity supply chain vulnerability was discovered in a Dependabot configuration file that lacked cooldown periods for package updates. Without cooldown settings, Dependabot could propose updates to newly published—and potentially malicious—packages immediately after release. The fix adds a 7-day cooldown period to all three package ecosystems (npm, GitHub Actions, and Maven), giving the community time to identify compromised packages before they're automatically proposed.

O
By Orbis AppSec
•Published July 4, 2026•Reviewed July 4, 2026
#security#supply-chain#dependabot#github-actions#yaml#dependency-management#devops

Answer Summary

Missing Dependabot cooldown is a supply chain security vulnerability in GitHub's `.github/dependabot.yml` configuration files where no delay is set before proposing updates to newly published packages. This exposes projects to dependency confusion and typosquatting attacks. The fix requires adding a `cooldown` block with `default-days: 7` to each `package-ecosystem` entry, ensuring Dependabot waits 7 days before suggesting updates to newly released package versions.

Vulnerability at a Glance

cweCWE-829 (Inclusion of Functionality from Untrusted Control Sphere)
fixAdd `cooldown: default-days: 7` to each package ecosystem configuration
riskAutomatic updates to malicious or unstable newly-published packages
languageYAML (GitHub Dependabot Configuration)
root causeNo `cooldown` block defined in `package-ecosystem` entries
vulnerabilityMissing Dependabot Cooldown Period

Introduction

In .github/dependabot.yml, a high-severity supply chain vulnerability was lurking in plain sight. The configuration defined three package ecosystems—npm at the root directory, GitHub Actions in /.github/workflows/, and Maven at the root—but none of them included a cooldown period. This meant Dependabot could immediately propose updates to packages the moment they were published, including potentially malicious ones uploaded by attackers exploiting dependency confusion or typosquatting attacks.

This vulnerability is particularly dangerous for Java services where servlets and controllers are remotely exploitable. A compromised Maven dependency could give attackers direct access to production systems.

The Vulnerability Explained

The vulnerable configuration at line 4 of .github/dependabot.yml looked like this:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/.github/workflows/"
    schedule:
      interval: "daily"

  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "daily"

Notice what's missing? There's no cooldown block in any of the three package ecosystem entries. This configuration tells Dependabot to check for updates on a schedule (daily for Maven and GitHub Actions, weekly for npm), but it doesn't tell Dependabot to wait before proposing newly published versions.

The Attack Scenario

Here's how an attacker could exploit this specific configuration:

  1. Reconnaissance: An attacker identifies that this Java service uses Maven dependencies with daily Dependabot checks.

  2. Package Takeover or Typosquatting: The attacker publishes a malicious version of a popular library or creates a typosquatted package name similar to one in the project's pom.xml.

  3. Immediate Proposal: Within 24 hours, Dependabot proposes the malicious package update as a pull request.

  4. Social Engineering: The PR looks legitimate—it's from Dependabot, after all. A developer merges it during routine maintenance.

  5. Compromise: The malicious code now runs in production, potentially exfiltrating secrets, creating backdoors, or compromising the Java servlet endpoints.

This attack vector is especially concerning because:
- The Maven ecosystem check runs daily, giving attackers a small window to strike
- GitHub Actions updates also run daily, meaning a compromised action could steal repository secrets
- The npm ecosystem, while weekly, still provides no protection against newly published malicious packages

The Fix

The fix adds a cooldown block with default-days: 7 to each of the three package ecosystem entries:

Before (Vulnerable)

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

After (Secure)

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

The complete fix applies this pattern to all three ecosystems:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7

  - package-ecosystem: "github-actions"
    directory: "/.github/workflows/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7

  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7

Why 7 Days?

The 7-day cooldown period is significant because:

  1. Community Detection Time: Most malicious packages are discovered and reported within a week of publication
  2. Registry Response Time: Package registries like npm and Maven Central typically remove malicious packages within days of reports
  3. Balance: 7 days provides protection without significantly delaying legitimate security updates

Each ecosystem needed the fix because:
- npm: JavaScript dependencies are frequent targets for supply chain attacks
- github-actions: Compromised actions can steal repository secrets and credentials
- maven: Java dependencies have direct access to production code execution

Prevention & Best Practices

1. Always Configure Cooldown Periods

Every package-ecosystem entry in your dependabot.yml should include:

cooldown:
  default-days: 7

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

2. Implement Additional Dependabot Security Settings

updates:
  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7
    # Additional security measures
    open-pull-requests-limit: 5
    reviewers:
      - "security-team"
    labels:
      - "dependencies"
      - "security-review"

3. Use Dependency Scanning Tools

Complement Dependabot with tools that verify package integrity:
- GitHub's dependency review action
- Snyk or Dependabot security alerts
- OSSF Scorecard for supply chain risk assessment

4. Enforce Code Review for Dependency Updates

Never auto-merge Dependabot PRs. Require at least one approval from a security-aware team member.

5. Monitor for Suspicious Packages

Set up alerts for:
- Newly published packages matching your dependencies
- Major version jumps in minor updates
- Packages with sudden ownership changes

Key Takeaways

  • The .github/dependabot.yml file had zero cooldown protection across npm, GitHub Actions, and Maven ecosystems—all three were vulnerable to immediate malicious package proposals
  • Daily Maven and GitHub Actions checks created a 24-hour attack window where malicious packages could be proposed immediately after publication
  • A 7-day cooldown is the minimum recommended protection—this gives the security community time to identify and report malicious packages
  • Each package-ecosystem entry needs its own cooldown block—there's no global setting that applies to all ecosystems
  • Supply chain attacks are increasingly common—the SolarWinds, Codecov, and ua-parser-js incidents demonstrate the real-world impact of dependency compromise

How Orbis AppSec Detected This

  • Source: Package registry (npm, Maven Central, GitHub Actions marketplace) publishing newly released package versions
  • Sink: Dependabot's automatic pull request creation at .github/dependabot.yml configuration
  • Missing control: No cooldown block with default-days value in any of the three package-ecosystem entries
  • CWE: CWE-829 (Inclusion of Functionality from Untrusted Control Sphere)
  • Fix: Added cooldown: default-days: 7 to all three package ecosystem configurations (npm, github-actions, maven)

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

This vulnerability demonstrates that security isn't just about the code you write—it's also about how you configure your development tools. A missing cooldown period in Dependabot configuration created a supply chain attack vector that could have led to malicious code running in production.

The fix was straightforward: add a 7-day cooldown to each package ecosystem. But the lesson is broader: always review your CI/CD configurations with a security mindset. Automated tools like Dependabot are powerful allies, but they need proper guardrails to avoid becoming attack vectors themselves.

For Java services with remotely exploitable endpoints, supply chain security is critical. A compromised dependency doesn't just affect your code—it affects every user who interacts with your application.

References

Frequently Asked Questions

What is a missing Dependabot cooldown vulnerability?

A missing Dependabot cooldown vulnerability occurs when your dependabot.yml configuration doesn't specify a waiting period before proposing updates to newly published packages. This allows potentially malicious or unstable packages to be immediately suggested for inclusion in your project.

How do you prevent missing Dependabot cooldown in GitHub?

Add a `cooldown` block with `default-days: 7` (or more) to each `package-ecosystem` entry in your `.github/dependabot.yml` file. This ensures Dependabot waits at least 7 days before proposing updates to newly released package versions.

What CWE is missing Dependabot cooldown?

Missing Dependabot cooldown relates to CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), as it can lead to the automatic inclusion of untrusted or malicious code from newly published packages.

Is using Dependabot alone enough to prevent supply chain attacks?

No. While Dependabot helps keep dependencies updated, without proper cooldown periods and security policies, it can actually increase supply chain risk by immediately proposing updates to newly published packages that may be malicious or compromised.

Can static analysis detect missing Dependabot cooldown?

Yes. Tools like Semgrep can analyze dependabot.yml files and flag configurations missing cooldown periods. The rule `package_managers.dependabot.dependabot-missing-cooldown` specifically detects this misconfiguration.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #7510
View Repository →

Related Articles

critical

How argument injection happens in Node.js Copilot tool bridge and how to fix it

A high-severity argument injection vulnerability was discovered in the Copilot tool bridge (`bridge.ts`) where user-controlled `request.args` were passed directly to `tool.execute()` without any validation or sanitization. The fix introduces Zod schema validation at line 108, ensuring that tool arguments are parsed against a declared `inputSchema` before execution. This prevents malformed or malicious payloads — including prototype pollution attempts — from reaching the underlying tool implement

critical

How command injection happens in Python os.popen() and how to fix it

A critical command injection vulnerability in `spk/itools/src/mounting.py` allowed arbitrary shell command execution through unsanitized iOS device names passed to `os.popen()` and `os.system()` calls. The fix replaced these dangerous functions with `subprocess.run()` using proper argument escaping, eliminating the shell injection attack vector.

high

How CORS credential reflection happens in Hono middleware and how to fix it

A high-severity CORS misconfiguration in Hono's middleware (CVE-2026-54290) allowed any origin to be reflected with credentials when the `origin` option defaulted to wildcard. This vulnerability in the studio frontend could enable attackers to steal authenticated user data through cross-origin requests. The fix upgrades Hono from 4.12.21 to 4.12.25, which properly handles CORS origin validation.

high

How integer overflow in malloc happens in C libregexp and how to fix it

A high-severity integer overflow vulnerability was discovered in QuickJS's libregexp.c where multiplication to compute allocation size could wrap around, causing a heap overflow. The fix replaces the unsafe `malloc(sizeof(capture[0]) * lre_get_alloc_count(bc))` pattern with `calloc(lre_get_alloc_count(bc), sizeof(capture[0]))`, which safely handles the multiplication internally and prevents exploitation.

critical

How buffer overflow via sprintf() happens in C++ settings parsing and how to fix it

A critical buffer overflow vulnerability was discovered in `app/src/main/cpp/samp/settings.cpp` where `sprintf()` writes to a fixed 127-byte buffer (`char buff[0x7F]`) without bounds checking. If the `g_pszStorage` global variable contains a string longer than ~107 bytes, the formatted output exceeds the buffer, enabling stack corruption. The fix replaces `sprintf()` with `snprintf()` using `sizeof(buff)` to guarantee writes never exceed the declared buffer length.

high

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

A high-severity supply chain vulnerability was discovered in a `.github/dependabot.yml` configuration file that lacked a cooldown period for package updates. Without a cooldown, Dependabot could immediately propose updates to newly published—and potentially malicious—package versions. The fix adds a 7-day `cooldown` block to both the npm and github-actions ecosystem entries, giving the community time to identify and flag compromised packages before they're adopted.