fix(action): a fork's branch name must not reach the shell holding the API key (rf-7xv0, rf-v2mj)

[Rome-1]

Closes sable-oubg (rf-7xv0 + rf-v2mj). P0, authorized by Rome 2026-09-13.

⚠️ Merging this without moving v1 changes nothing for any consumer

Both defects are live at the v1 tag, which is what consumers pin. v1 is 34850d46 — 115 commits and five months behind main. No fix that has ever landed on main has reached a consumer pinning v1. The fix and the tag move are one unit of work; this PR is only the first half.

Per the bead, I have not moved the tag. Flagging for review so the mayor can take the tag move to Rome.

rf-7xv0 — key exfiltration

"branch_name": "${{ github.head_ref || github.ref_name }}",

sat inside a run: block whose env: carries RAFTER_API_KEY. The runner expands ${{ }} into the script text before bash sees it, so that value was not data — it was source code, chosen by whoever opened the pull request. Anyone can open one from a fork.

Measured, not argued. With a branch name of:

x"; printf %s "$RAFTER_API_KEY" > "$CANARY_PATH"; echo "

the canary file came back containing the key. $( ) works too, and needs no quote-breaking at all.

Fixed the way GitHub documents: the values reach the script through env: (GH_REPOSITORY, GH_BRANCH), never through ${{ }} in run:. The body is then built with jq -nc --arg instead of pasted into a hand-quoted JSON string — which fixes a second bug in the same line: a branch name containing a quote or backslash produced malformed JSON even with no attacker involved.

rf-v2mj — an unreadable report rendered as a clean scan

COUNT=$(... | jq ... || echo "0") made "no findings" and "I could not read the output" the same value, so the gate passed precisely when it could not see its input. The count is now written only when a parse actually succeeded; otherwise the step fails and finding-count is left empty rather than a fabricated 0.

Note which file: the same defect class in github-action/action.yml was fixed under sable-fgk7, and this root action.yml was never touched by it. Two action files; only one had been fixed.

Probes — each fails on the pre-fix file, each has a control

probe	unfixed	fixed
test-trigger-injection.sh	3 failures	0
test-root-action-counts.sh	2 failures	0

Controls matter here: the count probe asserts a genuinely clean report still passes with count 0 and that real findings still count as 2. Without those, a "fail on everything" change would have passed.

The injection probe's fidelity control took two rewrites to become real — the first scraped the script text for the old inline-JSON shape and silently matched nothing once the fix removed it, and the probe did not model the step's env: block, so after the fix the payload arrived nowhere and the injection tests were passing vacuously. It now renders the env mapping the way the runner does, and checks the branch name round-trips against a real local listener that records the body actually sent.

CI

Both probes wired into test-github-action.yml. The workflow's path filter watched only github-action/**, so a change to the root action.yml would never have run the probe that guards it — action.yml added to both the pull_request and push filters.

Corpus searched

ref	file	head_ref/ref_name interpolations
main	action.yml	0
main	github-action/action.yml	1
v1	action.yml	0
v1	github-action/action.yml	1

Plus .github/workflows/test-action.yml and test-github-action.yml, which are workflows rather than actions and carry no such interpolation.

Not fixed here — reported, not silently left

A sweep of every ${{ }} inside a run: block found more of the same class, none attacker-controlled from a fork: the root action interpolates inputs.scan-path, inputs.args, inputs.format and inputs.version directly into run blocks, so a consumer whose workflow feeds untrusted text into those inputs has the same shape of problem one level out. github-action/action.yml also interpolates github.repository and github.event.pull_request.number, both runner-supplied and narrowly typed. Worth its own pass; not smuggled into a P0.