GitHub Actions blocks pull_request_target on 2 December

The GitHub Actions pull_request_target block starts by default in public repositories on 2 December 2026, unless an applicable Actions event policy allows the trigger, according to GitHub's 2 November changelog. Enforcement was previously due on 2 November. Maintainers of public repositories on GitHub Free, Team and Enterprise Cloud now have two scheduled test windows to find out which automation will stop before the block becomes permanent.

The primary sources are GitHub's changelog and its guide to controlling workflow execution.

The rollout runs in three stages.

• GitHub has scheduled two GitHub Actions brownouts, on 9 November and 16 November, each from 16:00 to 18:00 UTC. In those windows, blocked runs fail with an error annotation and the workflows do not execute.
• Between the windows the rule returns to evaluate mode, so workflows run with warnings. A repository can look healthy on 12 November and still break on 16 November.
• Permanent enforcement starts on 2 December. Security firm Wiz reports that the default policy has been in evaluate mode since 17 September, so some maintainers may have warnings waiting for them.

The default applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. Private and internal repositories are excluded, as is GitHub Enterprise Server. It does not disable every pull request workflow. The event at issue is specifically pull_request_target, which runs in the context of the base repository and can reach its secrets. If a workflow uses the event to run untrusted code from a contributor's fork, GitHub says that code could compromise the pipeline or steal secrets, while ordinary code review is untouched.

Before 9 November, teams should list every one of their pull_request_target workflows and note what each one does. A workflow that only labels or comments on a pull request is a different problem from one that checks out and runs a contributor's code. A search of the .github/workflows folder for the event name is a quick way to start.

GitHub tells maintainers to use Insights before the first brownout to see which runs the rule would block. Its changelog does not say which plans include Insights, so a maintainer without that view should rely on workflow definitions and the two brownouts. A workflow that has run successfully before is not proof that it is safe.

Where a workflow truly needs the trigger, an administrator can allow it in an applicable GitHub Actions event policy, and GitHub supports targeting individual workflow files. That is narrower than allowing the event everywhere. An exception should follow a review of secret access, token permissions and whether fork code is executed. Repository administrators, organisation owners and enterprise owners can set these policies at their own levels, and a stricter policy above may override a repository exception.

Gaps in the GitHub Actions pull_request_target block

The block is a narrow fix for a wide problem, and independent research on public repository workflow security shows where gaps remain. In an analysis published on 26 October, Wiz researcher Shay Berkovich describes the December change as a default, not a ban and sets out three risks it leaves in place.

• Workflows triggered by issue_comment, such as comment commands that deploy a pull request, are not covered by the same checkout protections.
• Script injection needs no checkout step. A workflow that places a pull request title directly into a shell command can run an attacker's text. Wiz recommends passing such values through an environment variable.
• Workflows pinned to a commit of actions/checkout released before the 20 July backport run older code without the fork checkout protections.

These points come from Wiz's research and are not tested by Industry Contents. They matter because a team that only allows or blocks the trigger can believe the job is finished when it is not.

For each public repository, decide before 9 November whether to replace the event, accept the block, or approve a narrowly scoped exception. GitHub has published the timetable, and the December date leaves time to change workflows, but the November brownouts will expose forgotten dependencies sooner. This brief does not claim to have tested a repository or to know how many teams will be affected.

Teams that also depend on open source projects can find more GitHub changes in our brief on Copilot access arriving on GitHub Enterprise Cloud plans and our list of 21 AI GitHub repositories to watch in November 2026.

Business context

List every workflow that uses pull_request_target, note whether it runs fork code or touches secrets, then decide to replace the trigger, accept the block or scope an exception.

Sources

• GitHub Changelog, 2 November 2026 · Primary source
• GitHub Docs, workflow execution policies · Primary source