CI/CD privilege escalation doesn't usually involve exploiting a vulnerability — it exploits the simple fact that the pipeline definition itself is often just as editable as application code, while carrying far more access.
The core problem
If a pipeline configuration file (a GitHub Actions workflow, a .gitlab-ci.yml, a Jenkinsfile) can be modified through a normal pull request, and that pipeline has access to sensitive secrets or deployment permissions, then modifying the pipeline is itself a path to accessing those secrets — no application vulnerability required.
A concrete example
A contributor opens a PR that modifies a workflow file to add a step that prints an environment variable, or sends it to an external endpoint, then triggers that workflow. If the modified pipeline runs with the same secrets as the legitimate one, this is a direct, low-effort path to exfiltrating credentials — entirely through a normal-looking pull request.
Why external fork protections aren't the whole answer
Most CI platforms restrict secrets from being exposed to pipelines triggered by pull requests from external forks by default — an important protection, but it only addresses the external contributor case. An internal team member (or a compromised internal account) with permission to modify pipeline files can still perform the same escalation, since internal pipeline runs typically do have secret access.
Protecting pipeline definition files specifically
Use CODEOWNERS (or equivalent) to require review specifically from a trusted, security-aware reviewer for any change to pipeline configuration files — treating them with the same or greater scrutiny as production infrastructure code, not as routine application changes.
Scope secrets to the specific job that needs them
Following least-privilege for CI tokens limits the blast radius even if a pipeline modification does occur — a compromised low-privilege pipeline should never have had access to high-privilege secrets in the first place, regardless of how it was modified.
Separate pipelines by trust level
A pipeline that only runs tests on every PR doesn't need the same secret access as a deployment pipeline that only runs on merges to a protected branch. Keeping these genuinely separate — different jobs, different secret scopes — limits what any single modified pipeline definition can actually reach.
Monitor pipeline definition changes
Alerting on changes to CI/CD configuration files specifically (beyond generic code review) gives an additional layer of visibility into exactly the kind of change most likely to represent an escalation attempt.