What

.github/workflows/release.yml expands the workflow_dispatch tag input straight into a shell:

run: |
  if [ ${{  github.event_name }} == 'workflow_dispatch' ]; then
    RELEASE_TAG=${{ github.event.inputs.tag }}

${{ ... }} is substituted as text before bash parses the line, and the assignment is unquoted, so a tag input containing shell metacharacters is executed rather than assigned.

That value then flows onward: it is written to GITHUB_ENV as RELEASE_TAG, POLYBAR_DIR and POLYBAR_ARCHIVE, and those are interpolated into the two actions/github-script bodies, which are JavaScript source:

const tag = '${{ env.RELEASE_TAG }}';
const fname = '${{ env.POLYBAR_ARCHIVE }}'
release_id: '${{ env.RELEASE_ID}}',

A single quote in any of them closes the string literal and the rest is evaluated as code, in steps holding GITHUB_TOKEN.

On severity: workflow_dispatch requires write access, so this is defense in depth, not an externally reachable vulnerability. I am raising it because the file already does the right thing one step further down — RELEASE_BODY is passed via env and read with process.env, with a comment explaining why — so this is mostly a consistency gap rather than a design disagreement.

The fix

Route every one of these through env: and read them with process.env, matching the existing RELEASE_BODY handling. Behaviour is unchanged.

Also adds permissions: contents: write to the job — the token needs to update releases and nothing more.

One thing worth flagging

The Get Version step carried:

if: ${{ github.event.inputs.tag }} != ''

Because this mixes an expression with trailing text, the result is a string — " != ''" on a release trigger — and any non-empty string is truthy, so the step always ran. That happens to be correct, since the else branch is what handles the release: published path.

Worth being explicit about the trap: "fixing" this to if: github.event.inputs.tag != '' would break automatic releases, because the step would then be skipped on the release trigger and RELEASE_TAG would never be set. The only correct fix is to drop the condition, which is what this PR does.

Verification

The workflow parses cleanly and no ${{ }} expansion remains inside any run: or script: body — every value now reaches them through env.

AI assistance

I used an AI coding agent to sweep release workflows for this pattern and to draft this description. What I confirmed in the file myself, rather than accepted from a model: that RELEASE_BODY further down the same job already goes through env: and is read with process.env, with a comment explaining why — so this is a gap in an approach the file had already chosen, not one I am importing — and that workflow_dispatch is the only path to the input, which is the basis for the severity note above.