GitHub's pull_request_target changes affect 269 of the 1,000 most-starred repositories

Two dated changes to one trigger

GitHub is altering the behaviour of the pull_request_target workflow trigger in two steps this year. According to an analysis published on dev.to, the first took effect on 20 July 2026, when actions/checkout began refusing to check out fork pull request code inside pull_request_target and workflow_run workflows unless maintainers explicitly opt in. The second lands on 2 November 2026, when GitHub will block pull_request_target on public repositories that lack an Actions policy — at repository, organization or enterprise level — permitting the trigger.

The trigger matters because workflows it starts run with the base repository's permissions and secrets, rather than the restricted access a fork contributor would otherwise get. That is exactly why placing untrusted fork code inside those workflows has long been considered dangerous.

Scanning the most-starred repositories

To measure the blast radius, the dev.to author built prt-check, a free checker available as a reusable Action or as a dependency-free Python script, and ran it across the 1,000 most-starred public, non-fork, non-archived repositories on 26 September 2026 — 37 days before the default block. The scan read only workflow YAML files under .github/workflows on default branches, 9,328 files across the 809 repositories that had any, and executed nothing. Only aggregate figures are published; no repository is named.

What the scan found

The headline figure: 269 of the 1,000 repositories (26.9%) run at least one workflow on pull_request_target, spread across 540 workflow files. Unless their maintainers allow the trigger through an Actions policy, that automation stops running on 2 November.

Beyond volume, the scan flagged specific risk patterns. Nine repositories (0.9%) check out fork pull request code in a privileged workflow using a post-guard version of actions/checkout, with no condition excluding forks. Those steps have failed for fork pull requests since 20 July, and label-gated variants fail the moment the label is applied.

Three repositories check out fork code with actions/checkout pinned to a version or commit from before the guard existed. The new refusal never fires for them, so fork code ends up sitting alongside the workflow's token and secrets. The report treats these as the cases to fix first, but declines to name them. Four repositories opted in deliberately by setting the allow-unsafe-pr-checkout option to true — a choice the author notes is safe only if no later step executes files from the fork. Nine more fetch pull request code directly through git fetch against pull refs or gh pr checkout, a path the new guard does not cover.

The invisible-policy caveat

Actions policies cannot be read from outside a repository, so the 269 figure counts workflows that depend on the trigger, not workflows certain to stop. Some of those repositories may already permit pull_request_target and keep running after November. The author also manually reviewed the repositories behind the fork-checkout findings and corrected the checker wherever the review disagreed, adjusting for job conditions, Dependabot-only jobs, workflow_run upstreams, branch filters and commit pins resolved to exact actions/checkout releases.

What runs on the trigger today

The most common uses are labelling and automation glue. Per the dev.to tallies, actions/github-script appears in 125 of the 269 repositories, actions/labeler in 50 and actions/create-github-app-token in 25, followed by setup steps for Node and Python, semantic pull request title checks, merge-conflict labelling, artifact upload and download, and contributor agreement handling.

Eight repositories run AI or review actions on the trigger: anthropics/claude-code-action on five, plus one each for presubmit/ai-reviewer, anthropics/claude-code-base-action and openai/codex-action. Those automated reviewers stop responding on 2 November unless the trigger is explicitly allowed.

What maintainers should do

The report recommends running prt-check against your own repository, then choosing one of three remedies: migrate the workflow to the unprivileged pull_request trigger, split it into pull_request plus workflow_run so untrusted checks run isolated from privileged steps, or keep pull_request_target deliberately and allow it through an Actions policy. The checker's source, tests and full method are published, and the author invites issue reports for false positives.

Why it matters

More than a quarter of GitHub's most popular projects depend on a trigger that switches off by default within weeks, and the disruption arrives in two waves: fork pull requests already break in workflows using the guarded checkout, while labelling, contributor agreements and AI reviewers go silent in November. The pinned-checkout cases are the sharper problem, because three widely used projects still place fork code inside privileged workflows — a known privilege-escalation route. And since Actions policies are invisible from outside, nobody can tell which of the 269 are already covered. That makes a self-audit the only dependable answer before the deadline.