How broken access control via supply chain dependency poisoning happens in TYPO3 with Dependabot and how to fix it

How Broken Access Control via Supply Chain Dependency Poisoning Happens in TYPO3 with Dependabot and How to Fix It

Introduction

In a TYPO3 project tracked via composer.lock, we discovered a high-severity supply chain vulnerability rooted not in the PHP application code itself, but in the project's .github/dependabot.yml configuration file at line 6. The Dependabot configuration for both the composer and github-actions package ecosystems lacked a cooldown block, meaning newly published package versions — including potentially malicious ones — could be immediately proposed as dependency updates.

This configuration gap is directly relevant to CVE-2026-47343 (TYPO3-CORE-SA-2026-007: Broken Access Control in File Abstraction Layer). Without a cooldown period, a compromised or typo-squatted package version could be proposed and merged before the security community has time to flag it, potentially introducing broken access control vulnerabilities into the File Abstraction Layer or any other TYPO3 component managed through Composer.

The vulnerable configuration looked like this:

updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"

No cooldown block. No quarantine window. Any package published seconds ago could be proposed immediately.

The Vulnerability Explained

What's Actually Happening

GitHub's Dependabot automatically monitors your project's dependencies and opens pull requests when new versions are available. By default, it proposes updates as soon as they're published to the package registry. This creates a dangerous window:

1. An attacker publishes a malicious version of a package (or a typo-squatted variant)
2. Dependabot immediately creates a PR proposing the update
3. If the PR is merged quickly (especially with auto-merge enabled), malicious code enters production

In the context of this TYPO3 project, the composer ecosystem manages PHP dependencies including TYPO3 core packages. The composer.lock file pins exact versions, but Dependabot's job is to update those pins. Without a cooldown, it does so indiscriminately.

The Attack Scenario

Consider this specific attack path against the vulnerable configuration:

1. An attacker identifies that this project depends on a TYPO3 extension or a transitive dependency
2. The attacker compromises the package maintainer's account (or publishes a typo-squatted package)
3. A new version is published containing code that weakens the File Abstraction Layer's access controls
4. Within minutes, Dependabot opens a PR: "Bump typo3/cms-core from 12.4.x to 12.4.y"
5. The PR passes CI (the malicious code is subtle — perhaps it modifies file permission checks)
6. A maintainer merges the PR, introducing CVE-2026-47343-class broken access control

The 7-day cooldown acts as a quarantine: if a malicious package is published, the security community typically identifies and reports it within days. By waiting 7 days, you let the ecosystem's immune system work before exposing your project.

Why This Configuration Matters

The .github/dependabot.yml file isn't just a convenience tool — it's part of your security boundary. It controls what code enters your project through automated means. A misconfigured Dependabot is essentially an automated attack surface that an adversary can trigger by publishing packages.

The Fix

The fix adds a cooldown block with default-days: 7 to both package ecosystem entries in .github/dependabot.yml:

Before:

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

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    labels:
      - "dependencies"
      - "github-actions"

After:

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

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    cooldown:
      default-days: 7
    labels:
      - "dependencies"
      - "github-actions"

Why Both Ecosystems Need the Fix

• composer ecosystem (line 6): This manages PHP/TYPO3 dependencies via composer.lock. A poisoned Composer package could directly introduce broken access control in the File Abstraction Layer.
• github-actions ecosystem (line 14): Compromised GitHub Actions can exfiltrate secrets, modify code during CI, or inject malicious artifacts. A cooldown here prevents adoption of newly-published action versions that may contain supply chain attacks.

How the Fix Works

The cooldown.default-days: 7 setting tells Dependabot: "Do not propose updates to any package version that was published less than 7 days ago." This creates a temporal buffer that:

1. Allows security researchers to analyze new releases
2. Gives package registries time to detect and remove malicious versions
3. Lets community reports surface on GitHub Issues, Twitter, or security advisories
4. Prevents zero-day supply chain attacks from being auto-proposed

Prevention & Best Practices

1. Always Configure Cooldown Periods

Every package-ecosystem entry in your Dependabot configuration should include:

cooldown:
  default-days: 7

For high-security environments, consider default-days: 14 or higher.

2. Avoid Auto-Merge on Dependency Updates

Even with cooldown periods, never auto-merge Dependabot PRs without human review. Use branch protection rules requiring approval.

3. Use Dependency Review Actions

Add actions/dependency-review-action to your CI pipeline to block PRs that introduce known vulnerabilities:

- uses: actions/dependency-review-action@v3
  with:
    fail-on-severity: high

4. Monitor composer.lock Changes

Any change to composer.lock should trigger enhanced review. Consider requiring CODEOWNERS approval for lock file modifications.

5. Pin GitHub Actions by SHA

Instead of version tags (which can be moved), pin actions by commit SHA:

- uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4.1.6

6. Scan with Semgrep

Use the Semgrep rule package_managers.dependabot.dependabot-missing-cooldown.dependabot-missing-cooldown in your CI pipeline to catch this misconfiguration automatically.

Key Takeaways

• A missing cooldown block in .github/dependabot.yml is not just a best-practice gap — it's an exploitable supply chain attack vector, especially for projects managing security-critical dependencies like TYPO3 core packages.
• The composer ecosystem entry at line 6 was the primary risk, as it controls PHP dependency updates that directly affect the TYPO3 File Abstraction Layer where CVE-2026-47343 manifests.
• 7 days is the minimum recommended cooldown — it aligns with the typical window in which the security community identifies and reports malicious package publications.
• Both composer and github-actions ecosystems needed the fix because supply chain attacks can enter through either dependency management path.
• Static analysis tools like Semgrep can detect configuration-level security gaps that traditional code scanners miss, making them essential for comprehensive security coverage.

How Orbis AppSec Detected This

• Source: Newly published package versions on Packagist (Composer) and GitHub Marketplace (Actions) — untrusted external input entering the dependency graph
• Sink: The updates entries in .github/dependabot.yml:6 and .github/dependabot.yml:14 that trigger automatic pull request creation without temporal validation
• Missing control: No cooldown block to enforce a quarantine period before proposing newly-published package versions
• CWE: CWE-1357 (Reliance on Insufficiently Trustworthy Component)
• Fix: Added cooldown: default-days: 7 to both the composer and github-actions package ecosystem entries, establishing a 7-day quarantine window

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 your code for vulnerabilities — it's about controlling how new code enters your project. A two-line YAML addition (cooldown: default-days: 7) creates a critical temporal defense layer that prevents the automatic adoption of malicious or unstable packages. In the context of CVE-2026-47343 and TYPO3's File Abstraction Layer, this cooldown could be the difference between catching a compromised dependency before it's proposed and discovering broken access control in production. Review your Dependabot configurations today — the fix takes seconds, but the protection is substantial.

References

• CWE-1357: Reliance on Insufficiently Trustworthy Component
• CWE-284: Improper Access Control
• OWASP Supply Chain Security Cheat Sheet
• GitHub Dependabot Cooldown Documentation
• Semgrep Dependabot Rules
• fix: this dependabot configuration does not set a co... in...