Secure pull_request_target in GitHub Actions

Untrusted contributor code runs only on pull_request, without repository secrets and with a read-only token. A pull_request_target workflow never checks out the pull request head, fetches its patch, runs its scripts, or restores state the fork can influence. If a privileged follow-up is necessary, it is a separate workflow that treats untrusted artifacts as data, not executable code.12

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npm test

Any GitHub user can open a fork pull request whose install or test code executes in the base repository's privileged context.

on:
  pull_request_target:

permissions:
  contents: write

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          # Intentionally unsafe: checkout v7 blocks fork PR heads on this
          # privileged trigger unless this opt-out is set.
          allow-unsafe-pr-checkout: true
      - run: npm ci
      - run: npm test

A target workflow can label a pull request or post a comment using trusted base-branch code, but every pull request field remains untrusted input. Do not interpolate titles, bodies, branch names, or labels directly into shell code. Keep permissions minimal and use least-privilege GitHub Actions permissions. The ci-secure skill detects privileged fork execution and related trust-boundary chains.

pull_request_target runs in the context of the base branch and can receive a privileged token or secrets that ordinary fork pull requests do not. Checkout v7 blocks fork PR head and merge refs on this trigger by default, but an explicit allow-unsafe-pr-checkout: true, a manual git fetch, or another execution path can bypass that layer. Executing the fork inside the privileged context turns an outsider's contribution into code execution with repository authority.

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

Audit workflows triggered by `pull_request_target` or another outsider-influenceable privileged event. If a job checks out a pull request head, fetches its patch, installs dependencies, runs repository scripts, restores fork-influenced state, or otherwise executes contributor content, move that work to an unprivileged `pull_request` workflow with read-only permissions and no secrets. Keep only metadata operations on `pull_request_target`, using trusted base-branch code and the minimum job permissions. Preserve the intended label, comment, or status behavior, 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/events-that-trigger-workflows#pull_request_target, 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