Pull request injection is opening a malicious pull request whose code or CI configuration runs in the target's pipeline when the PR is built. On misconfigured pipelines that build untrusted PRs with access to secrets, the attacker's PR reads runner credentials or reaches internal systems, without the PR ever being merged. Defend by never exposing secrets to untrusted-PR builds and requiring approval to run them.
What pull request injection is
Many pipelines build pull requests automatically so contributors get fast feedback. If those builds run with access to secrets and will build code from anyone, a pull request becomes a way to execute attacker code inside the trusted CI environment. The PR never has to be merged; being built is enough.
How it works and example
The attacker opens a pull request that changes a workflow or adds code that runs during the build, then the pipeline executes it with whatever access the runner has, dumping environment secrets or reaching internal services. This pwn-request pattern often hinges on triggers that expose secrets to untrusted PRs. A 2026 intrusion opened a malicious PR precisely to trigger credential probing in the runner.
How to defend against it
Never give secrets to builds of untrusted pull requests, and understand the difference between triggers that run in the base repo context and those that do not. Require maintainer approval before running workflows for first-time or external contributors, isolate PR builds without credentials, and review changes to workflow files as carefully as code.
References
- [1]OWASP Top 10 CI/CD Security Risks(OWASP)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]OWASP Top 10 CI/CD Security Risks(OWASP)
A stranger's pull request should not be able to read your CI secrets. Talk to a security expert about how your pipelines handle untrusted PRs.