GitHub Actions will block pull_request_target by default in public repositories

GitHub has made workflow execution protections generally available, giving repository administrators, organisation owners and enterprise owners an allowlist layer for who may trigger Actions workflows and which events may start them. Policies can be applied at repository, organisation or enterprise level and can now target individual workflow files, so a production deployment workflow can have tighter rules than ordinary CI in the same repository.

General availability also adds policy insights and a REST API. Enterprise Cloud customers can use evaluate mode to see which runs a rule would block before enforcement, while the API lets organisations manage actor, event and workflow-path conditions as policy-as-code rather than relying only on settings screens.

GitHub is also rolling out a default event policy for public repositories that do not already have an applicable event rule. The policy disables pull_request_target, initially in evaluate mode. GitHub says the default will be enforced automatically on 2 November 2026 for affected repositories that were still using the default pull_request_target policy before general availability.

Repositories that genuinely need the event can explicitly allow it through an applicable Actions policy, including for selected workflow files. Private and internal repositories are outside this new default, although administrators can create equivalent restrictions themselves.

The pull_request_target event runs in the security context of the base repository and can have access to repository secrets and write-capable credentials. That makes it useful for trusted tasks such as labelling or commenting on pull requests, but dangerous when a workflow checks out and executes untrusted code from a fork. GitHub describes this pattern as one of the most commonly exploited classes of Actions workflow vulnerability.

The new execution layer is designed to stop a risky event or actor before a workflow begins, even if an individual workflow file is misconfigured. It therefore complements permissions and workflow authoring practices rather than replacing them: explicitly allowing pull_request_target still leaves maintainers responsible for ensuring untrusted pull-request content is not executed in a privileged context.

Workflow execution protections can be applied at enterprise, organisation and repository scope. Evaluate mode also carries over from the public preview, allowing teams to see which workflow runs a rule would block before they enforce it.

The immediate operational task is to inspect the evaluate results before 2 November, identify public workflows that still depend on pull_request_target, and either move them to a safer trigger or make the exception explicit. The release confirms the new policy machinery and enforcement date; it does not establish that every existing pull_request_target workflow is vulnerable.