Introduction: GitHub Automation’s Double-Edged Sword
GitHub’s Dependabot automates dependency updates by submitting pull requests that patch known vulnerabilities. This significantly reduces the time it takes teams to secure their codebases. However, recent research shows that attackers are now manipulating these automation pathways to compromise supply chains. The root issue lies in overly permissive workflows that treat bot activity as implicitly safe.
The Confused Deputy Problem in CI/CD
The “Confused Deputy” problem occurs when a trusted entity is manipulated into performing actions on behalf of a malicious party. In GitHub workflows, this manifests when an attacker abuses conditions that check for github.actor == 'dependabot[bot]'. Many organisations configure workflows to auto-merge pull requests (PRs) from Dependabot, assuming they originate from a trusted source. In reality, attackers can manipulate forks, branch names, and event triggers to imitate Dependabot behaviour and inject unauthorised code.
For a technical breakdown, see Weaponizing Dependabot: PWN Request at its Finest.
How the Exploitation Works
1. Merge Conflict Rebinding
Attackers can generate merge conflicts in legitimate Dependabot pull requests, resolve them on a branch under their control, and rebind Dependabot’s update process to the malicious version. This can lead to unauthorised changes being merged if auto-merge is enabled and verification steps are minimal.
2. Branch Metadata Injection
In another variant, attackers change the default branch in a fork to one with harmful naming (such as embedded shell commands). If the project uses the @dependabot merge label or similar automated triggers, it may mistakenly pull in these unsafe branches into CI pipelines.
These techniques exploit the gap between trusted identity (dependabot[bot]) and untrusted source control.
Real-World Case Studies
NPM GitHub Actions Exploitation (2022)
Multiple open-source JavaScript projects using tj-actions/changed-files were found vulnerable to pull request injection. Malicious actors submitted pull requests (PRs) that manipulated metadata fetched during the build process. The consequence was unauthorised access to secrets and possible code execution on CI servers. Some projects were forced to revoke tokens, rotate secrets, and patch workflows.
More details available in GitHub Action tj-actions/changed-files Supply Chain Attack.
xz-utils Backdoor (2024)
Although unrelated to GitHub, the xz-utils supply chain compromise highlights the risks of relying too heavily on upstream automation. A malicious maintainer introduced a backdoor into xz compression libraries used across Linux distributions. If CI systems had auto-merged updates without auditing the source, millions of servers could have been silently compromised.
Read more in xz Backdoor Malware.
Mitigation Strategies
To defend against this class of exploit:
- Disable auto-merge on Dependabot PRs
- Require signed commits and verify commit integrity
- Avoid referencing dynamic branch metadata in workflows
- Restrict
GITHUB_TOKENpermissions in CI/CD jobs - Regularly audit workflow logic for implicit trust assumptions
A security guide on hardening workflows is available from Security Hardening for GitHub Actions.
Conclusion
Dependabot helps teams keep their dependencies secure, but when trusted blindly, it becomes a target for exploitation. As illustrated in these real-world examples, attackers can hijack automated update systems and exploit continuous integration (CI) workflows. The impact ranges from unauthorised code merges to complete CI server compromise.
Security engineers should treat automated agents with the same scrutiny as human developers. Assume no action is safe by default and architect your workflows to validate every step.