GitHub: Two Security Upgrades to GitHub Actions Protect Against Pwn Request Attacks

GitHub released two mutually complementary security upgrades for GitHub Actions on June 18, 2026. Both address the same fundamental problem: uncontrolled execution of code from untrusted sources in the privileged environment of a repository.

What Is a Pwn Request and Why Has It Been a Problem for Years?

A pwn request is an attack in which an external contributor opens a pull request from a fork, and the triggered workflow uses a privileged event — most commonly pull_request_target — giving it access to the secrets of the base repository. Unlike the standard pull_request event that runs in the isolated fork context, pull_request_target executes in the codebase context and has access to GitHub tokens and stored secrets. A single such attack can compromise an entire organization’s CI/CD pipeline.

actions/checkout@v7: Secure Defaults at the Action Level

The new version of the popular checkout action introduces protective behavior as the default: in privileged events like pull_request_target, the action refuses to fetch code from a fork PR. Instead, it checks out the base branch of the repository. This eliminates the most common pwn request scenario without any manual configuration. For teams whose workflows require the previous behavior, an opt-out flag is available. Backport to older versions of the checkout action is planned for July 16, 2026.

Workflow Execution Protections: Organization-Level Defense

In parallel, GitHub introduced Workflow execution protections into public preview — an administrative mechanism enabling the definition of actor and event-type allow-lists for an entire GitHub organization. Unlike checkout@v7, which protects at the level of individual steps within a workflow, this feature enforces policy before the workflow even begins executing. Admins can precisely specify who and which event type can trigger a workflow — external contributors, bots, and unknown actors can be systematically excluded or conditionally permitted, without the need to modify each individual workflow file.