Insecure Commands

Insecure Workflow Commands

Description

GitHub Actions once let steps set environment variables and modify PATH by printing ::set-env and ::add-path stdout commands. Because any process output could set variables, this was a code-execution sink and GitHub disabled it — unless the workflow opts back in with ACTIONS_ALLOW_UNSECURE_COMMANDS: true. 1 Re-enabling these commands (or using them directly) lets attacker-influenced output define variables like LD_PRELOAD/NODE_OPTIONS or prepend a directory to PATH, exactly like the modern GitHub Environment File Injection sink.

Vulnerable Instance

  • A workflow, job, or step sets ACTIONS_ALLOW_UNSECURE_COMMANDS: true.
  • Or a step still emits ::set-env / ::add-path stdout commands.
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ACTIONS_ALLOW_UNSECURE_COMMANDS: true   # re-enables the injectable commands
    steps:
      - run: echo "::set-env name=PATH::/tmp/evil:$PATH"

Mitigation Strategies

  1. Remove ACTIONS_ALLOW_UNSECURE_COMMANDS. There is no safe reason to re-enable the deprecated commands.
  2. Use the environment files. Migrate to $GITHUB_ENV and $GITHUB_PATH, and validate any user-controllable value before writing it (see GitHub Environment File Injection).
  3. Update old actions. If a dependency requires the flag, upgrade it to a version that uses the environment files.

Secure Version

 jobs:
   build:
     runs-on: ubuntu-latest
-    env:
-      ACTIONS_ALLOW_UNSECURE_COMMANDS: true
     steps:
-      - run: echo "::set-env name=FOO::bar"
+      - run: echo "FOO=bar" >> "$GITHUB_ENV"

Impact

DimensionSeverityNotes
LikelihoodLowUncommon in modern workflows, but persists in older ones and some third-party actions.
RiskHighRe-enables an injection sink that can execute code in later steps.
Blast radiusWideCode runs with the job’s secrets and token access.

References


Last updated on