GitHub to Restrict pull_request_target in Public Repositories Starting December 2

Starting December 2, 2026, GitHub will block GitHub Actions workflows triggered by pull_request_target in public repositories by default. As Habr reports, teams that need these workflows will have to explicitly allow the event in their Actions policies. The restriction was originally scheduled for November 2 but was postponed by a month.

Why this event is being restricted

pull_request_target is used to automate work with pull requests, including those from forks. A workflow might, for example, add a label or post a comment. The new rule is not about those actions themselves, but about the context in which the workflow runs.

It runs in the context of the base repository and may have access to its secrets. If the workflow also runs untrusted code from an external fork, an attacker could potentially steal secrets or interfere with CI/CD. GitHub is blocking these runs by default while leaving teams the option to keep the event enabled for workflows that genuinely need it.

Allowing the event does not eliminate the risk: what the workflow does after it starts matters too.

Timeline and repositories affected

The policy is currently in evaluate mode, so workflows continue to run. Administrators can already open Policy insights in GitHub Actions settings to see which workflows will stop running when blocking takes effect. This lets teams assess the impact in advance, before the restriction becomes permanent.

Before December 2, GitHub will temporarily enable blocking twice: November 9 and 16, 2026, each time from 16:00 to 18:00 UTC (19:00–21:00 Moscow time). During those windows, workflows covered by the new rule will not run. Instead, GitHub will create a failed run record with an error message. After each window, the policy will return to evaluate mode.

Starting December 2, blocking will become the permanent default. The change applies to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud. It will not affect private or internal repositories, and the new rule does not apply to GitHub Enterprise Server. That makes public repositories with workflows using pull_request_target the place to start checking.

What website teams should check

If your website is developed in a public repository, check Policy insights in GitHub Actions settings before November 9. A workflow running successfully now does not mean it will keep working after December 2: evaluate mode shows which restrictions will apply but does not yet stop workflows from running.

Once you have checked, review each affected workflow based on what it needs to do:

• If pull_request_target is not required, switch to pull_request where possible.
• If the task requires the event, allow it in the policy only for the workflow files that genuinely need it.
• If the workflow should not run, keep the default block in place.

For developers, the review does not end with the policy setting. GitHub recommends not running untrusted code from external pull requests when it has access to repository secrets or a privileged GITHUB_TOKEN. Allowing the event lets the workflow run again, but it does not make that combination safe. Protecting secrets matters beyond this change, too: the blog has previously covered active secrets found in public GitHub repositories.

Website owners and marketers do not need to understand workflow syntax. It is enough to ask the team whether any workflows in the public repository run on pull_request_target and whether they have checked what will happen to them on November 9 and 16, and then from December 2. If that automation is part of the pull request process, it is better to find out whether changes are needed before a workflow fails to run.

My take: simplify first, then allow

I would not make an exception just to preserve the existing behavior. First, I would find out why the workflow needs pull_request_target specifically and whether pull_request would do the job. In my experience, a solution with less access is easier to review and maintain than an exception whose purpose the team may eventually forget.

If the event really is necessary, I would limit permission to the workflows that need it and separately review what they do with code from external forks. It is worth discussing the decision as a team: the policy determines whether a workflow can start, but its safety also depends on what it runs and what it can access.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. GitHub с 2 декабря начнёт блокировать pull_request_target в публичных репозиториях habr.com

About the author

Rui Silva

Experienced full-stack developer

I build web services and help teams avoid overcomplicating architecture too early. I often explain to junior colleagues why a simple solution can be more reliable than a trendy one.

All posts by the author