fix(ci): harden release-pr workflow against expression injection

[antigenius0910]

Summary

Harden .github/workflows/release-pr.yml against GitHub Actions expression injection in the Resolve version step. The free-form inputs.version string was expanded into the run: bash script via ${{ inputs.version }} before bash ever saw the script, so a crafted input such as 0.8.0"; malicious_command; echo " would break the shell string context and execute arbitrary commands with the job's contents: write + pull-requests: write permissions and the generated App token.

Pass all workflow-context values (inputs.* and steps.*.outputs.*) through an env: block and reference them as "$VAR" inside the run scripts — the canonical GitHub-recommended pattern.

Discussion

• Discord: https://discord.com/channels/1491295327620169908/1491365158868619404/1526331374158610495

Threat model

• Trigger: workflow_dispatch → requires write access to the repo (mitigating), but still exposes insider-threat / compromised-credential paths.
• Blast radius: the job holds contents: write, pull-requests: write, plus an App token generated via actions/create-github-app-token@v3.
• Exploit shape: any ${{ inputs.version }} expansion inside a run: block. inputs.bump (type: choice) is validated at dispatch time so it is not directly exploitable, but env-hardening it too keeps the pattern consistent and guards against future type changes.
• Downstream flow: steps.version.outputs.version and .stable are derived from the tainted input unchanged, so Update version files and Create release PR are also hardened.

Files

File	Change
.github/workflows/release-pr.yml	Move every ${{ inputs.* }} / ${{ steps.*.outputs.* }} reference in a run: block into an env: block; use "$VAR" in shell

Test plan

• python3 -c "import yaml; yaml.safe_load(...)" on the edited workflow — parses clean
• Diff review: env vars added to Resolve version (INPUT_VERSION, INPUT_BUMP), Update version files (VERSION, STABLE), and Create release PR (VERSION alongside existing GH_TOKEN); all shell interpolations swapped to "$VAR"
• Maintainers: on next dispatch, verify the Resolve version step still resolves both auto-bump and explicit-version cases (behavior is unchanged — same variables, just passed through env)

Reference

• Reported via OX Security (issue 019d8c18-6fe2-7bb9-8b99-73f3be56b6ca)
• GitHub security hardening docs: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable

[antigenius0910]

Automated review bot (@chaodu-agent) has already LGTM-approved above. Flagging for maintainer eyes when convenient — happy to iterate on wording if useful.

[antigenius0910]

Force-refreshed CI on new SHA — all checks green. Ready for maintainer review.

[chaodu-agent]

Note

LGTM ✅ — Textbook fix for a real expression-injection vulnerability; env-block pattern is the canonical GitHub-recommended mitigation.

What This PR Does

The release-pr.yml workflow expanded ${{ inputs.version }} directly inside run: shell blocks, allowing a crafted version string to escape the shell context and execute arbitrary commands with contents: write + pull-requests: write permissions. This PR passes all inputs.* and steps.*.outputs.* values through env: blocks and references them as properly-quoted "$VAR" in shell.

How It Works

Three run: steps are hardened:

1. Resolve version — INPUT_VERSION and INPUT_BUMP added to env:, shell uses "$INPUT_VERSION" / "$INPUT_BUMP"
2. Update version files — VERSION and STABLE added to env:, removing inline ${{ }} expansion
3. Create release PR — VERSION added alongside existing GH_TOKEN in the env block

No behavioral change — same logic, just a safer delivery mechanism for variable values.

Findings

#	Severity	Finding	Location
1	🟢	Correct canonical mitigation pattern applied consistently across all three vulnerable steps	.github/workflows/release-pr.yml
2	🟢	Proper double-quoting of env vars in shell ("$INPUT_VERSION", "$INPUT_BUMP") prevents word-splitting/globbing	.github/workflows/release-pr.yml:44-55
3	🟢	Defensive hardening of inputs.bump despite choice-type validation — future-proofs against type changes	.github/workflows/release-pr.yml:41
4	🟢	Excellent threat model documentation in PR description	PR body

Finding Details

🟢 F1: Canonical mitigation applied correctly

All ${{ inputs.* }} and ${{ steps.*.outputs.* }} references in run: blocks are moved to env: blocks. This is exactly what GitHubs security hardening guide recommends.

🟢 F2: Proper shell quoting

Every env var reference uses double quotes ("$VAR"), preventing word-splitting and globbing issues even with unusual version strings.

🟢 F3: Consistent hardening

Even inputs.bump (a type: choice input not directly exploitable today) is hardened through env. This prevents a regression if the input type is ever relaxed.

🟢 F4: Threat model documentation

The PR body clearly documents the attack vector, blast radius, and exploit shape — excellent for future reference.

Baseline Check

• PR opened: 2026-07-13
• Main already has: release-pr.yml with direct ${{ inputs.version }} expansion in run blocks (vulnerable)
• Net-new value: Eliminates expression injection attack surface in the release workflow

What's Good (🟢)

• Minimal, focused diff — changes only whats necessary
• No behavioral change, pure security hardening
• Well-documented threat model and test plan
• Follows GitHubs official recommended pattern exactly
• CI passes (YAML parses clean)

5️⃣ Three Reasons We Might Not Need This PR

1. workflow_dispatch requires write access — An attacker already needs repo write access to trigger this workflow, which limits the exploit surface to insider threats or compromised credentials. However, defense-in-depth is valid.
2. Existing branch protection could limit blast radius — Even with contents: write, branch protection rules on main would prevent direct pushes. But the App token could still be exfiltrated or used for other API calls.
3. No evidence of active exploitation — This is a proactive hardening rather than an incident response. However, the OX Security report indicates external scanners are flagging this class of vulnerability, so fixing proactively is prudent.

All three reasons are outweighed by the low-risk, high-value nature of this fix. The change is minimal, behavioral-neutral, and eliminates a real (if mitigated) attack vector.