Key takeaways
- GitHub Actions will block pull_request_target by default in public repositories on December 2, 2026, after an earlier date of November 2.
- GitHub will enforce the block in two test windows, 16:00 to 18:00 UTC on November 9 and November 16.
- Maintainers can keep the trigger by allowing it in an Actions event policy, which can target specific workflows.
GitHub will block pull_request_target by default in public repositories on December 2, 2026, according to its changelog. Workflows that use it will stop running unless a repository, organization or enterprise policy explicitly allows the trigger. GitHub had earlier set the enforcement date to November 2.
The change matters to any maintainer who runs automation on pull requests from forks, such as labeling bots, coverage comments or AI code-review agents. Many of those workflows use this trigger because it can write to the repository. That is also what makes it risky.
Why GitHub is blocking it
GitHub's stated reason is short: pull_request_target runs in the context of the base repository and can access its secrets. If a workflow checks out and runs code from a fork, that untrusted code gets the same access. A malicious pull request could then steal secrets or compromise the build pipeline.
The plain pull_request trigger does not have this problem for forks, because it runs without the repository's secrets.
Who is affected
The default block applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. Private and internal repositories are not affected, and neither is GitHub Enterprise Server.
Two test windows before December 2
Before the permanent change, GitHub will enforce the block during two short windows, from 16:00 to 18:00 UTC on November 9 and again on November 16. In those windows, a blocked pull_request_target run fails with an error annotation and does not execute. Between the windows, the rule goes back to evaluate mode: workflows run, but warnings appear.
What to do before November 9
GitHub's changelog gives two options.
- Use Insights to see which workflow runs the rule would block, and leave the default in place if none of them need the trigger.
- If a workflow depends on the trigger, allow it explicitly in an applicable Actions event policy. Workflow file targeting lets you allow only specific workflows rather than the whole repository.
GitHub's documentation on controlling workflow execution describes event policies as a "Restrict events" rule that lists which events can trigger the targeted workflows. The page does not give click-by-click steps for the new default, and points to a separate article, "Securely using pull_request_target", for details. Our earlier report on GitHub outages that hit Actions covers a different problem, but it is a reminder of how many projects depend on Actions running.
What we don't know yet
The changelog does not say what happens to workflows that allow the trigger through an old policy, or whether GitHub will move the date again. It already moved once, from November 2 to December 2. Check the brownout results on November 9 before you decide the date is safe to ignore.