GitHub to block pull_request_target workflows in public repos from 2 December 2026

GitHub Actions will block workflows that use the pull_request_target trigger by default in every public repository from 2 December 2026, according to a dev.to post published on 6 November. Two two-hour brownouts, on 9 and 16 November, will temporarily enforce the block so maintainers can find breakage before it becomes permanent.

What changes and when

GitHub announced the change on 2 November 2026 and at the same time pushed enforcement back a month, from 2 November to 2 December, the post explains. Until then the rule runs in evaluate mode: GitHub logs which workflow runs it would block without actually blocking them, and those findings appear in a repository's Insights tab.

The brownouts act as a dry run. On Monday 9 November and Monday 16 November, between 16:00 and 18:00 UTC, GitHub will enforce the block for two hours; any pull_request_target workflow in an affected repository fails with an error annotation and does not execute. Outside those windows the rule returns to evaluate mode. From 2 December the block is permanent unless an Actions event policy explicitly allows the trigger, and GitHub recommends scoping any exception to specific workflow files rather than the trigger in general.

The scope is narrow: only public repositories on GitHub Free, Team and Enterprise Cloud are affected. Private, internal and GitHub Enterprise Server repositories are exempt.

Why the trigger is risky

An ordinary pull_request event raised from a fork runs with a read-only token and receives no repository secrets, so hostile fork code has little to steal. pull_request_target is the exception: it executes in the base repository's context, with a write token and access to secrets, which is what lets bots label, comment on and triage fork pull requests.

The weakness is not the trigger itself but the combination of that privileged context with untrusted code. In the classic pattern the post describes, a workflow checks out the pull request's head commit and runs build or test steps with a secret in the environment; a contributor quietly edits package.json so installation executes a post-install script, and the script sends the secret to an external server. The workflow file is trusted because it lives on the base branch, yet everything it runs comes from the fork.

The author's guidance is to treat everything arriving through the pull request as untrusted input. To run a fork's code, use a separate pull_request workflow, or the pull_request plus workflow_run pattern, where an unprivileged workflow runs the code and a privileged one acts on its artefacts after a maintainer approves.

What a scan of major projects found

The author measured rather than speculated, scanning 202 workflow files across five large public repositories on 6 November 2026 with a small Python script. Twenty-seven workflows, about 13 per cent, use pull_request_target, and after manual review none of them executes fork code.

The breakdown: github/docs has 101 workflows with 11 on the trigger, nodejs/node 45 with 5, facebook/react 26 with 4, python/cpython 23 with none, and actions/checkout 7 with none. The Node and React cases are label, comment and notification bots that never run fork code.

One flagged workflow, review-comment.yml in github/docs, turned out to be a false positive: it references the head SHA and contains run steps, but it checks out the base repository without overriding the ref and passes the head SHA only as data. The author's conclusion is that an automated scan is a starting point, not a verdict — every flagged file deserves a manual read.

How to prepare

Two checks are recommended before the 9 November brownout. First, open the repository's Insights tab and read the workflow execution protection findings already collected in evaluate mode — a quieter signal than a failing build. Second, scan workflow files directly; the post includes a short unauthenticated script that walks a repository's default branch through the GitHub API and flags any workflow that both references the pull-request head and contains run steps.

Why it matters

pull_request_target can hand a repository's secrets to arbitrary fork code, and blocking it by default closes off a whole class of secret-leaking incidents in open source. The cost falls on the minority of workflows that legitimately depend on the trigger — roughly one in eight in the sampled repositories — and especially on those that also execute fork code, which must be rewritten. Maintainers of public repositories have a defined window: read the evaluate-mode findings now, audit before the first brownout, and either migrate to the safer pull_request and workflow_run pattern or carve out a narrow policy exception before 2 December.