GitHub Actions will start blocking pull_request_target workflow runs in all public repositories on 2 December 2026 unless a repository‑level Actions event policy explicitly permits the trigger.
Change Overview
The new default rule is introduced through the workflow execution protections feature. Initially it operates in “evaluate” mode, meaning runs are not stopped but are flagged so owners can see which workflows would be blocked. After two scheduled brownout windows in November, the rule will move to permanent enforcement.
Brownout schedule (UTC):
- 9 November 2026 16:00–18:00
- 16 November 2026 16:00–18:00
During each window any pull_request_target attempt that would be blocked creates a failed run with an error annotation; the workflow does not execute. After the window the rule reverts to evaluate mode, emitting warnings instead of hard failures.
Why It Matters for Engineers
The pull_request_target trigger runs in the context of the base repository and inherits its secret store. When a forked pull request supplies untrusted code, that code can read or exfiltrate secrets, potentially compromising downstream pipelines or leaking credentials. By default‑blocking the trigger, GitHub reduces the attack surface for public projects on Free, Team, and Enterprise Cloud plans.
Security‑focused engineers should treat this as a change to the implicit trust model of fork‑based contributions. Cloud and platform teams must reassess any CI/CD patterns that rely on pull_request_target for secret access.
Operational Impact and Mitigation Steps
Practitioners have three practical paths before the permanent rule activates:
- Leave the default block in place and redesign workflows to avoid
pull_request_targetwhen secret access is required. - Create an explicit Actions event policy that allows the trigger for the repository.
- Use workflow‑file targeting to whitelist specific workflow files that need the permission.
GitHub’s Insights view can be used ahead of the first brownout to identify which runs would be blocked. Adjusting policies or workflow definitions before 9 November 2026 avoids unexpected failures during the brownout windows.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Expect a shift from implicit secret availability in fork‑based PRs to an explicit allow‑list model. Review all public repositories for pull_request_target usage, verify that required secrets are only accessed in trusted contexts, and update event policies or workflow files accordingly before the 9 November brownout. Monitoring the evaluate‑mode warnings will give you a clear inventory of affected pipelines, allowing you to plan remediation without service disruption.
