GitHub announced on November 2, 2026 that, starting December 2, GitHub Actions will block pull_request_target events by default in public repositories unless an Actions event policy explicitly allows the trigger. The original date was November 2 and was pushed back a month. Before that there are two test windows with real blocking, from 16:00 to 18:00 UTC: November 9, the day this was published, and November 16.
What the block changes
pull_request_target runs in the context of the base repository, with access to its secrets, even when the pull request comes from a fork. That is why the trigger is used for tasks that need credentials on outside contributions: labeling PRs, posting results, publishing a preview, running a review bot. For the same reason, a workflow that executes fork code in that context can leak secrets or compromise the pipeline. GitHub cites this risk as the reason for the new default.
During the test windows, runs that would be blocked fail with an error annotation and do not execute. Outside them, the rule stays in evaluate mode: workflows run, with a warning. On December 2 the block applies all the time.
Who is affected
Public repositories on GitHub Free, Team and Enterprise Cloud are in scope. Private and internal repositories are not, and neither is GitHub Enterprise Server. A repository that already has an applicable event policy follows that policy instead of the new default.
In practice, the impact falls mostly on maintainers of open source projects with outside contributions and on companies that publish libraries, SDKs, plugins or themes in public repositories and have automated PR triage. If a company's product lives only in private repositories, this change does not reach it.
This is the second restriction on the same trigger this year. Since July 20, actions/checkout (v7 and the earlier major versions still supported) refuses by default to fetch fork code in pull_request_target, and only does so with the allow-unsafe-pr-checkout input. That change limited what a workflow could fetch; this one stops the workflow from starting.
What to do before December 2
The first step is knowing which workflows depend on the trigger. A search for pull_request_target in .github/workflows across public repositories answers that, and GitHub points to Actions Insights to see which runs the rule would block. A pull_request_target failure inside the test windows comes from the block, not from the infrastructure.
Then, for each workflow found, there are two ways out:
- if it needs no secrets and no write permission, switch to
pull_request, which runs without the base repository's secrets on fork PRs; - if it does, create an event policy that allows the trigger, scoped to that workflow's file. GitHub recommends this per-file scope over allowing the whole repository.
The second case calls for reviewing the workflow itself: if the allowed workflow runs anything that comes from the fork, such as a build script, dependencies installed from the PR or a command built from PR text, it stays as exposed as before, now with explicit permission. Preview workflows fall into this group when they combine outside code with deploy credentials. The same reasoning applies to the resources a preview can reach, as I discussed in A safe preview must isolate connected resources.
The decision belongs to whoever administers the organization or repository on GitHub. A policy created at the organization level applies to every public repository at once, which means agreeing on it with each project's maintainers.
What is still unclear
The announcement does not say whether the default will reach private and internal repositories, or whether something equivalent will come to GitHub Enterprise Server. The enforcement date has also changed once, and some of the material in circulation still cites November 2. GitHub's changelog is the reference for planning the change.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
