hunting-cicd-workflow-injection

name	hunting-cicd-workflow-injection
description	Hunt a CI/CD pipeline for attacker-controlled repository data that reaches a privileged execution context, after the trigger and the token scope are resolved. Covers an untrusted event field (an issue or pull-request title, a branch name, a commit message) interpolated directly into a run-step shell command, a pull_request_target or workflow_run job that checks out and builds the pull-request head with secrets in scope, a third-party action pinned to a mutable tag or branch rather than a commit digest, a cache a low-trust job writes and a privileged job restores and executes, a self-hosted runner reachable from fork pull requests, and an over-scoped pipeline token widening the blast radius. Use when reviewing workflow definitions, their triggers, and their token permissions, not the OIDC trust boundary the CI OIDC skill owns. Attacker-controlled repository data is the source, a privileged pipeline run step or checkout is the sink, and untrusted input reaching execution is the bug.
license	MIT

Hunting CI/CD workflow injection: attacker repository data reaching a privileged run step

A CI/CD pipeline turns dangerous where data an outside contributor controls, an issue title, a branch name, a pull-request body, the contents of a fork, reaches a step that runs with the repository's secrets and write token. The two headline shapes are an expression that interpolates an untrusted event field straight into a shell command, and a privileged trigger that checks out and builds the untrusted pull-request head. You hunt it by resolving, per workflow, what triggers it (and therefore whether secrets and a write token are in scope) and then following each untrusted field to the run step or checkout it reaches. The discipline is separating an untrusted value interpolated into a shell from one passed safely through an environment variable, and a privileged trigger that runs untrusted code from one that only reads metadata. The OIDC trust boundary is the CI OIDC skill's; this skill owns data reaching execution.

When to use

• You are reviewing CI/CD workflow definitions, their triggers, and their token or secret scope.
• A workflow interpolates event data into a run step, or builds a pull request, or uses third-party actions.
• You want to know whether an outside contributor can reach a privileged step through repository data.

Scope check

Audit only pipelines in repositories you own or are authorized to assess, and trigger a workflow only against a repository in scope, a proof-of-concept run executes with real secrets and a real token. Adjudicate on the workflow and its trigger. If you can't name the authorization, stop.

The loop

1. Resolve the trigger and the token scope first. For each workflow, read the trigger and determine whether it runs with secrets and a write-scoped token in scope. A plain pull-request trigger runs a fork's job without secrets and with a read-only token; a pull_request_target, a workflow_run, or a push or issue trigger runs in the base repository's context with secrets. The trigger decides whether an injected value has anything worth reaching, so settle it before flagging.

2. Check untrusted expression interpolation. Look for an event field an outsider controls (an issue or pull-request title or body, a branch or label name, a commit message, an author name) interpolated directly into a run-step shell command, so the field's shell metacharacters execute.

3. Check the privileged-checkout shape. Look for a pull_request_target or workflow_run job that checks out the pull-request head ref and then builds, tests, or runs a script from it, executing untrusted code with the base repository's write token and secrets available.

4. Check action pinning and cache trust. Look for a third-party action referenced by a mutable tag or a branch rather than a full commit digest, so an upstream tag move injects new code, and for a cache a low-trust job writes with a key a privileged job restores and executes.

5. Check runner and token blast radius. Look for a self-hosted runner reachable from fork pull requests (non-ephemeral, carrying persistent state) and for a token scoped wider than the workflow needs (a broad write-all permission) that widens the damage any of the above can do.

6. Confirm and record. Confirm by setting the untrusted field to a payload (or opening a fork pull request) and showing the injected command runs, or the untrusted head executes, with secrets or the write token in scope. Kill the lead if the untrusted expression is assigned to an environment variable first and the step references the quoted variable (the canonical safe pattern) rather than interpolating it into the command string, if the trigger is a plain pull request so the fork job runs without secrets and a read-only token (and no self-hosted runner or explicit secret is present), if a pull_request_target job never checks out the head ref and only reads metadata (a labeler), if the action is pinned to a full commit digest even with a version comment, if the untrusted field is structurally constrained (a numeric identifier) and cannot become a shell token, or if repository or organization policy blocks fork workflows from running without approval and the runner is ephemeral. Record the workflow, the trigger, the untrusted field, and the privileged step it reaches.

Where pipeline injection leaks

• The trigger decides whether there is anything to steal. A plain pull-request job runs without secrets and read-only; a target, workflow_run, push, or issue trigger runs with secrets, which is where injection pays.
• Interpolation into the shell is the bug; an env variable is the fix. An untrusted field spliced into a run command executes its metacharacters; the same field passed through a quoted environment variable does not.
• A privileged trigger that builds the head runs untrusted code. pull_request_target and workflow_run give the base-repo token and secrets; checking out and building the fork head hands them to the attacker.
• A mutable action tag is a supply-chain sink. A tag or branch reference lets upstream inject new code; a full commit digest pins it, and the pinning satisfied kills the finding.
• Scope amplifies everything. A self-hosted non-ephemeral runner and a write-all token turn a small injection into lateral movement; ephemeral runners and least-scoped tokens bound the blast radius.

Worked example (a confirm and a kill)

Confirm. A workflow triggered on new issues has a run step echo "Issue: ${{ github.event.issue.title }}". An attacker opens an issue titled with a shell payload; the pipeline interpolates it into the command and executes it in a context that has repository secrets. Confirmed command injection through an untrusted event field interpolated into a run step with secrets in scope, high rising to critical with a write token, remediation = pass the title through a quoted environment variable and never interpolate untrusted event data into a run command.

Kill. The same title flows through env: TITLE: ${{ github.event.issue.title }} and the step runs echo "Issue: $TITLE", referencing the quoted variable. The value is data to the shell, not command text, and the workflow uses the default read-only token. Killed, kill_reason = "the untrusted value is passed through a quoted environment variable rather than interpolated into the command string, so it cannot become shell syntax."

Rationalizations to reject

• "It just echoes the title." -> Interpolated into the command with ${{ }}? Then the title's metacharacters run; only a quoted environment variable makes it inert data.
• "Pull requests can't touch secrets." -> A plain pull-request trigger cannot, but pull_request_target and workflow_run run in the base context with secrets; check which trigger this is.
• "The action is pinned to v3." -> A tag is mutable; upstream can move it. Only a full commit digest is a pin; a floating tag is a supply-chain sink.
• "The target workflow only labels." -> Does it check out the head ref? If it only reads metadata it is fine; if it builds the fork head, it runs untrusted code with the token.
• "The runner is ours." -> A self-hosted non-ephemeral runner reachable from fork pull requests carries state between runs; that persistence is the lateral-movement path.

Executing this in practice

You need each workflow, its trigger and whether that trigger carries secrets and a write token, every place an untrusted event field is interpolated into a run step, every privileged-trigger job and whether it checks out the head ref, the action references and whether they are digest-pinned, the cache keys crossed between jobs, the runner type, and the token permissions. For each untrusted field, decide whether it reaches a privileged step as command text or untrusted code. Reading the workflow tells you the path; triggering it tells you whether the injection runs.

Related

• auditing-cicd-oidc-trust - owns the pipeline's OIDC trust boundary (which cloud identities the workflow can assume); this skill owns attacker-controlled data reaching execution, an orthogonal source and sink.
• hunting-supply-chain-risks - the broader dependency and artifact-integrity audit; the mutable-action-tag shape here is the pipeline-local edge of that supply-chain surface, cross-referenced rather than duplicated.
• hunting-non-human-identity-and-secret-reachability - the secrets a compromised pipeline step can reach; a confirmed injection here is the execution primitive that makes those secrets reachable.
• FINDING-SCHEMA.md - source = attacker-controlled repository data, sink = a privileged pipeline run step or checkout, evidence = the trigger scope, the untrusted field, and the executed command or untrusted head.