ENGINEERING NOTE / UPDATED OCT 16, 2026

GitHub's November 2026 `pull_request_target` policy: a readiness checklist.

On November 2, 2026, GitHub says it will enforce a default policy blocking pull_request_target runs in affected public repositories. Here's how to identify workflows that need a decision—and how to avoid converting a compatibility fix into a security problem.

Scope matters. According to GitHub's current guidance, the default policy targets public repositories without an applicable Actions event policy. It does not apply to private or internal repositories and does not replace an applicable existing policy. A YAML scan alone cannot determine whether a specific repository will be blocked.

1. Find workflows that use the event

Search your checked-out repository for the event in .github/workflows. This does not require any credentials and does not change existing configuration.

grep -RIn --include='*.yml' --include='*.yaml' \
  'pull_request_target' .github/workflows

If you have many repositories, repeat the check for each organization/repository. Record the repository, workflow path, job, and reason for using a privileged event. Presence is not proof of a vulnerability or a guaranteed block.

2. Check the repository's actual policy insights

For affected public repositories, GitHub says the default event policy is currently in evaluate mode: workflow runs continue, while policy insights indicate what would be blocked under enforcement. Repository administrators can inspect Actions policies and policy insights from repository settings. The same settings exist at organization or enterprise level for appropriately authorized administrators.

Official navigation: Settings → Actions → Policies → Policy insights, where supported. Confirm the applicable policy and its intended effect instead of assuming that every pull_request_target workflow will stop.

3. Make a deliberate decision, not a blanket allow rule

Option A: use `pull_request` where possible

When the job's purpose is to build or test code from external contributors without privileged repository access, prefer pull_request. Fork PR workflows are subject to reduced token privileges and secret restrictions; ensure your job does not unnecessarily request writes.

Option B: retain a narrow trusted workflow

If the job must label, triage, or perform trusted side effects, keep the privileged step separate from untrusted PR code. Use minimum token permissions, avoid executing checkout content from the fork, and review applicable policy configuration with the repository administrator.

Don't enable a broad exception merely to make the previous CI status green. GitHub's documented policy mechanisms can allow required events in a carefully scoped way, but that decision should be justified by your trust model.

4. Review the dangerous checkout-and-execute pattern

A particularly risky flow occurs when pull_request_target is used and the workflow checks out an external PR head, then executes files from it in a privileged job. GitHub documents this as a “pwn request” pattern. It is not enough to check the event name; follow which code is actually executed.

# Illustrative insecure pattern: DO NOT COPY into production
on: pull_request_target
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm test  # executes untrusted PR content in privileged context

Later checkout protections may reject some unsafe fork-head checkouts by default. That is a safety control, not a reason to turn on allow-unsafe-pr-checkout indiscriminately. The same hazard can appear through git fetch, downloading PR artifacts, dependency scripts, or alternative checkout mechanisms.

5. Add a repeatable, read-only preflight

Workflow Risk Check flags the use of pull_request_target for review and identifies selected risky combinations of checkout, permissions, self-hosted runners, and script execution. It runs locally in the browser or as a GitHub Action. It cannot check organization policy configuration, approval history, every path that runs untrusted code, or the runtime behavior of third-party actions.

If the scanner finds a high-severity pattern, examine the steps and data flow manually. If it finds nothing, you still need to check event policies and actual job security boundaries.

TOOLS & REMEDIATION

Free scan first. Scoped fixes when needed.

Use the no-upload checker now. For a small repo with several workflows, request a non-sensitive scope review before sharing any private code.

Run free checker ↗Ask about a fix →

References and limitations

한국어 버전 보기 ↗

This is an operational interpretation of publicly documented GitHub guidance available on October 16, 2026—not an official GitHub announcement. Policy dates and enforcement details may change. Confirm current settings and official documentation before changing production CI.

GitHub's November 2026 pull_request_target policy: a readiness checklist.