Prevent GitHub Actions cache poisoning

Pull request jobs can restore approved dependency caches but cannot create trusted release state. Release and publish jobs either install from verified lockfiles without a shared cache or use a separate cache namespace writable only by trusted triggers. Cache paths exclude build outputs, hooks, credential files, and anything later executed without verification.12

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read

jobs:
  release:
    runs-on: ubuntu-latest
    environment: release
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v6
        with:
          node-version: 22
      - run: npm ci --ignore-scripts
      - run: npm run build
      - run: npm test

An attacker who influences the shared workspace can replace executable output that a later privileged job trusts and publishes.

on:
  workflow_dispatch:
    inputs:
      head_repository:
        required: true
        type: string
      head_sha:
        required: true
        type: string
  push:
    tags:
      - "v*"

jobs:
  cache-untrusted-head:
    if: github.event_name == 'workflow_dispatch'
    runs-on: ubuntu-latest
    steps:
      # workflow_dispatch can write caches, but these inputs can select a fork.
      - uses: actions/checkout@v7
        with:
          repository: ${{ inputs.head_repository }}
          ref: ${{ inputs.head_sha }}
      - uses: actions/cache@v4
        with:
          path: .
          key: shared-workspace

  release:
    if: startsWith(github.ref, 'refs/tags/')
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/cache@v4
        with:
          path: .
          key: shared-workspace
      - run: ./dist/publish

GitHub.com now gives low-trust triggers read-only access to default-branch cache scope, including pull_request_target, issue_comment, and workflow_run; a save attempt from those triggers fails. The architectural rule still matters for GitHub Enterprise Server, third-party cache backends, trusted triggers that fetch untrusted content, and any cache containing executable state. The ci-secure skill reports candidate cache/trust-boundary patterns with this platform mitigation so you can distinguish a blocked GitHub.com path from a reachable residual.

Keep private keys, cloud credentials, auth files, package-manager tokens, and whole workspaces out of cache paths. A cache is an optimization that may disappear or be replaced; a trusted job must be able to rebuild and verify its inputs from the repository and lockfile.

Caches outlive one job and are restored implicitly by key and scope. If an untrusted run can write executable or credential-bearing state that a trusted job restores, the attacker crosses from an unprivileged contribution into the release path without modifying the protected branch.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.

Audit GitHub Actions caches across trust boundaries. Map each cache key, scope, backend, writer, and restorer. Identify any cache an untrusted or attacker-influenceable workflow can write that a release, deploy, publish, or secret-bearing job later restores, plus cache paths containing whole workspaces, executable outputs, or credential files. Remove caches from privileged release paths when possible; otherwise create a trusted-only namespace and cache only inert dependency data. Preserve build reproducibility, show the diff, and open a PR rather than applying it blindly.

Ground these changes in the upstream docs before you edit: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching, https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.

If you do not know why a run is slow yet, start with the diagnostic guide. Let an agent find which of these applies: /ci-speedup. If your workflows are already optimized but still slow, see our guide to fast GitHub Actions and GitHub Actions runner alternatives. Building containers in CI? The Docker workflow guide covers layer caching end to end. Want to see how your configuration measures up before changing anything? CI Score grades workflow config against a pass/fail rubric of these practices. It is not a speed measurement.

• GitHub Actions too slow
• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions pricing
• Self-hosted GitHub Actions runners
• Docker CI on GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup