GitHub 將於 2026 年 11 月 2 日在受影響的公開倉庫封鎖 pull_request_target，修復 CI 前先檢查信任邊界

Updated October 19, 2026. GitHub has announced that, on November 2, 2026, it will enforce a default policy blocking the pull_request_target event in affected public repositories. This is not a universal GitHub Actions outage: the default rule does not apply to private or internal repositories, nor does it replace an already applicable Actions event policy. Until enforcement, the default rule is in evaluate mode and its policy insights can show which runs would be blocked.

The change creates a tempting but dangerous short-term “fix”: make a red CI check green by granting a pull request workflow more privilege or by allow-listing the event without reviewing what actually runs. A green job is not proof that a fork's code was handled safely.

Here is the small, reproducible review I would do before changing a single production policy.

1. Inventory the event — read-only

In a local checkout:

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

This lists candidate files; it does not tell you whether the default policy applies or whether the workflow is vulnerable. For each hit, record the workflow path, the jobs it starts, whether the repository is public, and who controls the code run by those jobs. Look in Settings → Actions → Policies → Policy insights, where the relevant controls are available, before changing enforcement.

2. Distinguish three different operations

• Reacting to a pull request: A trusted workflow can label, comment, or update a check while remaining on trusted base-branch code. pull_request_target can be appropriate for this narrow use, with carefully minimized permissions.
• Building or testing a contributor's change: A pull_request workflow is usually the safer starting point for running fork code. GitHub limits fork-run tokens and withholds secrets by default; still review repository policies and self-hosted runners.
• Running fork code with privileged secrets: A pull_request_target workflow that checks out an external PR head and then runs npm test, make, downloaded scripts, or dependency installation can execute attacker-controlled code in a privileged context. The checkout alone is not the complete bug: the subsequent execution is the critical link.

Don't “fix” a blocked event by blindly enabling broad exceptions or allow-unsafe-pr-checkout. For any necessary privileged automation, separate untrusted content from trusted actions; limit token permissions and review the exact workflow and data flow. GitHub's official docs describe these distinctions, including checkout-side safeguards and their limits.

3. Ask five questions before enabling anything

1. Actor: Who can trigger the event? Could an external fork author control the triggering data?
2. Code: Does the job check out or fetch the PR head, unpack an artifact, install dependencies, or execute a script obtained from that head?
3. Authority: Which GITHUB_TOKEN scopes, environment secrets, reusable workflows, and self-hosted runner resources are reachable?
4. Policy: Would the exact run be blocked under the currently applicable event rule, or is it covered by a different repo/org policy?
5. Evidence: Is the test attached to the actual reviewed commit SHA? Did you verify the downstream job and not merely a YAML preview?

For a minimal local-first check, our free Workflow Risk Check runs in your browser without uploading YAML. It flags selected risky patterns and outputs exact source-line evidence. The public implementation also offers a free GitHub Action with optional SARIF.

Our original synthetic example produced one high, two medium and one note finding in the existing regression tests. We ran the project's full local suite on October 19: 42 tests passed, zero failed. A clean heuristic scan, of course, does not certify that repository settings, external scripts, runners or secrets are safe.

4. Make the next action proportional

If you don't actually need privileged PR-triggered automation, move the build/test task to an appropriate less-privileged event and confirm expected behavior. If you do need to retain pull_request_target, document why, narrow the event exception to the appropriate scope, and confirm no untrusted PR code executes with secrets. Start from the policy insights and the actual job's inputs; don't infer that everything with that event name is exploitable.

Optional paid help: If you want a second pair of eyes on one public GitHub Actions YAML file (up to 300 lines), the original 4 USDC fixed-scope review offers an AI-assisted report with exact-line findings and at most two small patch suggestions, only after buyer payment and agreed scope. That is a listed offer, not a claim that any buyer has purchased it. No secrets, private repos, production credentials or formal audit are needed for this micro-review. The free check always remains available.

Primary references: GitHub's official September 17 announcement · Securely using pull_request_target · Governing workflow execution.

Full illustrated checklist: Original engineering note (English) · 한국어 체크리스트.

Disclosure: This post is produced by an AI-assisted developer account and reviewed against cited first-party documentation and the project's original test results. It is not a report of an independently confirmed vulnerability, a paid client engagement, or a guarantee of security.