GitHub Actions pull_request_target enforcement starts November 2, 2026 for public repos

GitHub is moving a new default event policy for Actions from evaluate mode to active enforcement on November 2, 2026, and maintainers of public repositories that rely on the pull_request_target event could see jobs stop running when the switch happens. According to an independently prepared technical explainer published on dev.to on October 20, 2026, which cites GitHub's official documentation, the underlying workflow execution protections became generally available on September 17, 2026. Enforcement begins November 2 for affected repositories that were still using the default policy before general availability.

Who is affected

The dev.to article notes that the new default applies only to public repositories without an Actions event policy already configured at the organization or repository level. Existing policies are not replaced, and private or internal repositories are out of scope. Repositories still in evaluate mode continue to run workflows normally while GitHub records which runs would have been blocked, so policy insights are the place to look before the deadline. The article cautions against reading too much into the signals either way: a single warning does not mean the whole repository is unsafe, and no warning does not prove the workflow YAML is sound.

Why pull_request_target is risky

The event exists because some automation needs to respond to pull requests from forks while holding write access to base-repository metadata, such as applying labels. The trade-off is that workflows triggered by pull_request_target run with the trust, permissions and secrets of the base repository rather than the read-only context a fork contribution would normally get.

The explainer lists the patterns GitHub itself warns about: checking out an untrusted fork's head and then running package installation, a test runner, build script or shell inside the privileged job; interpolating fork-supplied text into shell commands without a robust handling boundary; granting broad write permissions or secrets to a job that only reads metadata; and sharing caches or artifacts across trust boundaries without a deliberate design. GitHub's actions/checkout also ships specific protections for this scenario, along with an opt-out input named allow-unsafe-pr-checkout. The article stresses that using the opt-out does not make untrusted code execution safe, adds review obligations, and should not be used merely to suppress a warning.

What to check before the deadline

Search .github/workflows files for pull_request_target and ask why each workflow needs it. Building and testing proposed changes generally belongs on the low-privilege pull_request event with read-only contents permission; pinning third-party and first-party Actions to reviewed commit SHAs strengthens dependency integrity further.

Where privileged behavior is genuinely required, the article recommends separating trust boundaries: keep contributor-supplied code out of the privileged job, and if the only privileged operation is an API update after CI finishes, evaluate a separate trusted workflow with explicit authorization and provenance checks rather than running untrusted contribution code in the privileged context. The author also suggests recording evidence per workflow — whether the default policy applies, which specific API operation needs the event, whether the job ever runs contributor code, whether a low-privilege pull_request run passes instead, and how narrowly any exception is scoped. A rollback path should be documented, and the article warns against allowing the event everywhere or deploying a blanket checkout opt-out just to keep CI green, since that recreates the exposure the policy exists to close.

One caveat: the dev.to piece is an independent explainer rather than an official GitHub announcement, and its author notes that GitHub may update the policy's dates and terms after publication, so the official Actions documentation remains the authoritative reference.

Why it matters

There are two plausible failure modes here. The first is disruption: repositories that ignore evaluate-mode findings may find jobs unexpectedly blocked once enforcement begins on November 2, 2026. The second is worse: a rushed fix that broadly re-enables pull_request_target or disables checkout protections reintroduces a known supply-chain attack path in which untrusted fork code executes with access to repository secrets. A focused audit now — identifying which workflows need the event, moving the rest to pull_request, and isolating whatever privileged operations remain — avoids both outcomes.