**GitHub** is taking a proactive step to enhance software supply chain security by updating its 'actions/checkout' functionality. The move directly addresses **pwn request attacks**, a vulnerability that exploits the risky use of the 'pull_request_target workflow' trigger, allowing malicious code to execute with full workflow privileges. ### The 'actions/checkout' Update Starting June 18, 2026, the latest version of **actions/checkout**, the official **GitHub** action for checking out a repository into a workflow's runner, will by default refuse common pwn request patterns. This critical change is also slated to be backported to all currently supported major versions by July 16, 2026. According to **GitHub**, "**Actions/checkout v7** refuses to fetch fork pull request code in **pull_request_target** and **workflow_run** workflows (the latter only when workflow_run.event is a pull_request* event)." ### How the Blockade Works The refusal mechanism activates when a pull request originates from a fork and meets specific criteria, unless workflow authors explicitly opt out by setting the "allow-unsafe-pr-checkout" flag to "true" in **actions/checkout**. These criteria include: * The repository resolving to the fork pull request's repository. * The ref matching `refs/pull/number/head` or `refs/pull/number/merge`. * The ref resolving to a fork pull request's head or merge commit SHA. This update is designed to prevent the most prevalent forms of pwn requests within the **Actions** ecosystem. As a consequence, **actions/checkout** will fail for **pull_request_target** events from forks that contain insecure inputs. ### Understanding the 'pull_request_target' Risk **Pull_request_target** is a workflow trigger that automatically runs when a pull request is opened, reopened, or updated. Crucially, this event runs in the context of the base repository's default branch. This context can expose secrets and a privileged **GITHUB_TOKEN** with both read and write permissions. **GitHub's** documentation highlights the danger: "Running untrusted code on the **pull_request_target** trigger may lead to security vulnerabilities." These vulnerabilities can manifest as **cache poisoning** or granting unintended access to write privileges or sensitive secrets. ### The Mechanics of a Pwn Request Attack The core danger arises when **pull_request_target** is combined with **actions/checkout** to download and execute code submitted by an untrusted fork. If a malicious actor submits a pull request with harmful scripts, and the workflow proceeds to check out and run this code, the attacker can steal the **GITHUB_TOKEN** and other secrets, leading to a **pwn request attack**. **GitHub** elaborates: "Workflows triggered by **pull_request_target** run with the base repository's **GITHUB_TOKEN**, secrets, and default-branch cache access. Checking out the head of an unreviewed pull request from a fork inside one of these workflows typically lets attacker-controlled code execute with the workflow's full privileges." ### Real-World Impact and Past Incidents This vulnerability has been weaponized in several recent software supply chain attacks. Notable incidents include: * The compromise of multiple packages associated with the **Nx build system** as part of the **s1ngularity** campaign. * Breaches affecting **PostHog**. * Compromises of **TanStack**. * The popular Emacs package, **kubernetes-el/kubernetes-el**. **Socket**, a software supply chain security firm, noted that while **pull_request_target** was intended for trusted automation (like labeling or commenting), the checkout step is critical. "If it pulls code from a forked pull request, the workflow can end up running attacker-controlled code with the base repository's privileges." ### Limitations and Recommendations It's important to note that this change specifically targets **pull_request_target** events involving `actions/checkout` and fork pull request heads/merge commits. Pwn requests triggered by other event types (e.g., `issue_comment`) or via other means (e.g., git or the **GitHub CLI**) are outside the scope of this update. **GitHub** advises developers to: * Assess and use **pull_request_target** only when absolutely necessary. * Switch to **pull_request** if the workflow does not require elevated permissions or secret access. * Restrict permissions granted to workflows. * Ensure user-controlled input does not lead to the execution of untrusted code. **Socket** emphasizes that this update serves as a guardrail, not a complete solution. "Workflows that run with secrets, write permissions, deployment permissions, or **OIDC** publishing access still need careful review."