CI/CD pipeline poisoning is abusing a continuous-integration pipeline to run attacker-controlled code in a privileged build environment. A malicious commit, pull request, or dependency triggers the pipeline, which then exposes runner secrets, cloud credentials, and deploy keys, or ships tampered artifacts to production. Because pipelines are trusted and hold powerful credentials, one poisoned build can reach production. Defend by isolating untrusted builds, least-privilege runners, and reviewing pipeline changes.
What CI/CD pipeline poisoning is
A CI/CD pipeline runs code automatically with access to secrets, cloud credentials, and the ability to deploy. Pipeline poisoning gets attacker-controlled code, whether in a commit, a pull request, or a dependency, to execute inside that trusted environment, turning the build system itself into the attack surface.
How it works and example
The attacker introduces code or a build-config change that the pipeline runs, then uses that execution to dump runner environment variables, read cloud credentials, sign or publish tampered artifacts, or reach internal systems the runner can touch. In a 2026 intrusion, a malicious pull request was opened specifically to trigger credential probing in the runner environment.
How to defend against it
Isolate builds of untrusted code so they never see secrets, and give runners least-privilege, short-lived identities such as OIDC-federated cloud credentials. Require review for changes to pipeline definitions, pin and verify dependencies, separate build from deploy privileges, and monitor pipeline runs for unexpected commands, network calls, or secret access.
References
- [1]OWASP Top 10 CI/CD Security Risks(OWASP)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]MITRE ATT&CK: Supply Chain Compromise (T1195)(MITRE ATT&CK)
Your pipeline holds the keys to production. Talk to a security expert about testing what a poisoned build could reach.