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:
- An attacker publishes a malicious version of a package (or a typo-squatted variant)
- Dependabot immediately creates a PR proposing the update
- 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:
- An attacker identifies that this project depends on a TYPO3 extension or a transitive dependency
- The attacker compromises the package maintainer's account (or publishes a typo-squatted package)
- A new version is published containing code that weakens the File Abstraction Layer's access controls
- Within minutes, Dependabot opens a PR: "Bump
typo3/cms-corefrom 12.4.x to 12.4.y" - The PR passes CI (the malicious code is subtle — perhaps it modifies file permission checks)
- 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
composerecosystem (line 6): This manages PHP/TYPO3 dependencies viacomposer.lock. A poisoned Composer package could directly introduce broken access control in the File Abstraction Layer.github-actionsecosystem (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:
- Allows security researchers to analyze new releases
- Gives package registries time to detect and remove malicious versions
- Lets community reports surface on GitHub Issues, Twitter, or security advisories
- 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
cooldownblock in.github/dependabot.ymlis 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
composerecosystem 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
composerandgithub-actionsecosystems 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
updatesentries in.github/dependabot.yml:6and.github/dependabot.yml:14that trigger automatic pull request creation without temporal validation - Missing control: No
cooldownblock to enforce a quarantine period before proposing newly-published package versions - CWE: CWE-1357 (Reliance on Insufficiently Trustworthy Component)
- Fix: Added
cooldown: default-days: 7to both thecomposerandgithub-actionspackage 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.