Security: CI command injection via `github.ref_name` in release workflow

[coderabbitai]

Summary

The release workflow embeds ${{ github.ref_name }} directly inside a run: Bash block. GitHub Actions expression expansion occurs before the shell parses the script, so a syntactically valid tag name containing shell metacharacters — e.g. v1.2.$(id) — causes command substitution to execute on the runner. The vulnerable step runs with contents: write and exposes GITHUB_TOKEN/GH_TOKEN, so any user able to push a matching tag could execute arbitrary commands in the release job, exfiltrate the token during its lifetime, or tamper with release publication.

Affected commit: 45e3bde
Reported via: PR #323

Evidence

• .github/workflows/release.yml lines 4–7: workflow triggers on tag pushes matching v*.*.*; this glob pattern matches tag names that include $() shell metacharacters.
• Lines 118–121: the release job is granted contents: write.
• Lines 129–142: ${{ github.ref_name }} is interpolated directly into a Bash run: script while GITHUB_TOKEN and GH_TOKEN are set as environment variables.

Validation confirmed:

• git check-ref-format refs/tags/v1.2.$(printenv>leaked_env) returns success — the crafted tag is accepted by Git ref syntax.
• A local emulation of the vulnerable step executed the command substitution and produced a leaked_env file containing the fake token values; the safe env-var variant did not.

Attack Path

1. Attacker (or compromised trusted account) creates/pushes a tag matching v*.*.* whose name includes shell metacharacters.
2. The release job triggers; GitHub Actions expands ${{ github.ref_name }} into the Bash script before the shell parses it.
3. Command substitution executes on the GitHub Actions runner in a step that holds GITHUB_TOKEN/GH_TOKEN and contents: write.
4. Attacker can exfiltrate the ephemeral token, create or tamper with releases, or inject malicious artifacts into the release pipeline.

Severity

High — exploitation requires repository tag-push capability or a compromised trusted account; the token appears scoped to this repository rather than broader organisation credentials. Impact is nonetheless high: arbitrary runner command execution, release integrity compromise, and potential supply-chain risk for consumers of published release artefacts.

Recommended Fix

Pass the tag name through an environment variable and reference it as "$TAG_NAME" in the shell script rather than interpolating the Actions expression directly. Optionally, add strict validation (e.g. a regex guard) before any shell use of the tag name.

Controls Already Present

• Repository authentication is required to push tags.
• Top-level workflow permissions are contents: read; the release job explicitly elevates.
• Shared actions are pinned to commit SHAs.
• Pull-request dry-run workflow sets contents: read and passes dry-run: true.

Blindspots

• Live GitHub tag protection/ruleset configuration was not confirmed via static review.
• Downstream adoption of published release artefacts determines the full supply-chain blast radius.

---

Reported by @leynos.

[leynos]

@CodeRabbit plan

[coderabbitai]

Coding Plan

Summary

• Adopt environment variable indirection as the primary mitigation: the GitHub context value is assigned to an env: variable, and the shell script references "$TAG_NAME", ensuring the value is treated as data rather than code.
• Add an explicit regex validation step as defence in depth to reject tags not conforming to semantic versioning before any shell processing.
• Scope the fix strictly to the release workflow; composite action vulnerabilities discovered during exploration are separate concerns and outside this ticket's remit.

Implementation Steps

Remediate Command Injection in Release Workflow

Eliminate the script injection vulnerability by passing github.ref_name through an environment variable rather than interpolating it directly into the shell script. Add a validation step as defence in depth to reject malformed tag names before any shell processing occurs.

Task 1: Convert Direct Interpolation to Environment Variable Indirection

Replace the unsafe direct interpolation of ${{ github.ref_name }} within the run: block with a shell variable reference.

• Update .github/workflows/release.yml lines 129–142 to add TAG_NAME: ${{ github.ref_name }} to the env: block of the "Ensure release exists (draft)" step
• Replace all occurrences of ${{ github.ref_name }} inside the run: script body with "$TAG_NAME" (double-quoted to prevent word splitting and glob expansion)
• The three substitution points are: the gh release view argument, the gh release create argument, and the --notes string

Task 2: Add Tag Name Validation Step

Insert a validation step before the "Ensure release exists (draft)" step to enforce that the tag conforms to strict semantic versioning format, providing defence in depth against unexpected input.

• Add a new step in .github/workflows/release.yml immediately before the draft release step (around line 129)
• Name the step "Validate tag format"
• Set TAG_NAME: ${{ github.ref_name }} in the step's env: block
• In the run: block, use a Bash regex test ([[ "$TAG_NAME" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$ ]]) to confirm the tag matches the expected pattern
• Exit with a non-zero status and emit a ::error:: annotation if validation fails

🤖 Prompt for AI agents

Remediate the command injection vulnerability in `.github/workflows/release.yml`
by applying environment variable indirection and adding a tag validation step.
The goal is to ensure `github.ref_name` is never interpolated directly into a
shell `run:` block.

**Task 1 — Convert Direct Interpolation to Environment Variable Indirection:**
- Open `.github/workflows/release.yml` and locate lines 129–142 (the "Ensure
release exists (draft)" step)
- Add `TAG_NAME: ${{ github.ref_name }}` to the `env:` block of that step
- Replace every occurrence of `${{ github.ref_name }}` inside the `run:` script
body with `"$TAG_NAME"` (double-quoted)
- Apply the replacement at all three substitution points: the `gh release view`
argument, the `gh release create` argument, and the `--notes` string

**Task 2 — Add Tag Name Validation Step:**
- Insert a new step in `.github/workflows/release.yml` immediately before the
"Ensure release exists (draft)" step (around line 129)
- Set the step's `name` to `Validate tag format`
- Add `TAG_NAME: ${{ github.ref_name }}` to the step's `env:` block
- In the `run:` block, write a Bash regex test using `[[ "$TAG_NAME" =~
^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$ ]]` to confirm the tag matches the
expected semantic versioning pattern
- If the validation fails, exit with a non-zero status and emit a `::error::`
workflow annotation

Research

The repository uses GitHub Actions workflows stored in .github/workflows/. The release workflow (.github/workflows/release.yml) triggers on tag pushes matching v*.*.* and elevates permissions to contents: write for the release job. Lines 129–142 contain the vulnerable step where the tag name is passed unsafely to gh release commands. The workflow also calls an external pinned composite action for asset uploading, but that is outside the repository's direct control.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Remediate the command injection vulnerability in `.github/workflows/release.yml`
by applying environment variable indirection and adding a tag validation step.
The goal is to ensure `github.ref_name` is never interpolated directly into a
shell `run:` block.

**Task 1 — Convert Direct Interpolation to Environment Variable Indirection:**
- Open `.github/workflows/release.yml` and locate lines 129–142 (the "Ensure
release exists (draft)" step)
- Add `TAG_NAME: ${{ github.ref_name }}` to the `env:` block of that step
- Replace every occurrence of `${{ github.ref_name }}` inside the `run:` script
body with `"$TAG_NAME"` (double-quoted)
- Apply the replacement at all three substitution points: the `gh release view`
argument, the `gh release create` argument, and the `--notes` string

**Task 2 — Add Tag Name Validation Step:**
- Insert a new step in `.github/workflows/release.yml` immediately before the
"Ensure release exists (draft)" step (around line 129)
- Set the step's `name` to `Validate tag format`
- Add `TAG_NAME: ${{ github.ref_name }}` to the step's `env:` block
- In the `run:` block, write a Bash regex test using `[[ "$TAG_NAME" =~
^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$ ]]` to confirm the tag matches the
expected semantic versioning pattern
- If the validation fails, exit with a non-zero status and emit a `::error::`
workflow annotation

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!