GitHub has pushed back the date on which GitHub Actions will stop running pull_request_target workflows by default in public repositories. Enforcement was planned for November 2, 2026, and is now set for December 2, 2026, according to the GitHub changelog.
Two short brownout windows come first, so maintainers can find workflows that depend on the trigger. If your public repository uses pull_request_target, this is the time to review it.
What Is Changing
The block comes from a default rule in GitHub's workflow execution protections. Until now the rule has run in evaluate mode, which means it only reports what it would have stopped. After December 2 it will actually block those events unless an Actions event policy allows them.
The change covers public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories are not affected, and neither is GitHub Enterprise Server.
Why GitHub Is Doing This
The pull_request_target trigger runs in the context of the base repository, not the fork that opened the pull request. That gives the workflow access to repository secrets, which is useful for tasks like labeling or commenting on pull requests from forks.
The danger appears when such a workflow checks out and runs code from the fork. Untrusted code then executes with trusted access, and it could steal secrets or tamper with your pipeline. The default rule is meant to cut this risk for projects that never needed the trigger.
The Brownout Schedule
Before permanent enforcement, GitHub will turn the block on twice for two hours each time. During these windows, blocked attempts in affected public repositories will show up as failed runs with an error annotation, and the workflows will not execute.
- November 9, 2026, from 16:00 to 18:00 UTC
- November 16, 2026, from 16:00 to 18:00 UTC
After each window the rule returns to evaluate mode, and workflows run again with warnings.
What It Means for Developers
If none of your workflows use pull_request_target, you do not need to do anything, and you gain a safer default. If some do, the brownouts are a free dry run: a failed run during those hours tells you which workflow depends on the trigger.
Open source maintainers who run bots for labeling, triage or welcome messages are the most likely to be hit. Many of these jobs can be rewritten to use the plain pull_request trigger, or to split the work so that privileged steps never touch fork code.
How to Prepare
GitHub suggests using Insights to see which workflow runs the rule would block before the first brownout on November 9. From there you have two choices:
- Keep the default rule in place and let it block the trigger.
- Allow pull_request_target explicitly in an applicable Actions event policy, and use workflow file targeting to permit only the specific workflows that need it.
If you do allow it, review each workflow carefully. Avoid checking out the pull request head branch in a job that has secrets, and keep permissions for the token as small as possible.
Conclusion
The one-month delay gives public repositories extra time to audit their workflows, but the direction is clear: pull_request_target will be blocked unless you opt in. Check Insights now, test during the November brownouts, and write an explicit policy for any workflow that truly needs the trigger.
Sources
See my articles more often when you search Google.
