The Pwn Request Reckoning What Still Works Against GitHub Actions
The Pwn Request Reckoning: What Still Works Against GitHub Actions
GitHub’s 2026 Actions changes make pull_request_target attacks harder, but not impossible. For years, pull_request_target has been the canonical Pwn request vector: a workflow trigger that runs with repository secrets, yet can be triggered by anyone who opens a pull request from a fork. In 2026, GitHub responded with platform changes that make the default-case exploit significantly harder. These changes represent real progress, with checkout protections, read-only cache tokens, and event policies closing paths that made exploitation trivial. However, they don’t eliminate the vulnerability class; they shift it.
GitHub spent 2026 systematically closing the gap through a phased rollout of platform-level protections and action updates. On June 18, 2026, actions/checkout@v7.0.0 was released, blocking fork code checkouts by default in untrusted triggers (pull_request_target, and workflow_run triggered by pull requests). On July 20, 2026, fork checkout protections were backported across all active major versions of actions/checkout (v2.8.0, v3.7.0, v4.4.0, v5.1.0, and v6.1.0). Workflows referencing mutable version tags (e.g., @v4) inherited these defenses automatically. Finally, on December 2, 2026, GitHub is scheduled to begin enforcing the default event policy that blocks pull_request_target in public repositories without an explicit event policy. Private and internal repositories are not affected.
While this sequence of platform updates significantly strengthens default security configurations for GitHub Actions, they don’t remove all risk. The December 2 enforcement is a default, not a ban. Maintainers whose automation depends on pull_request_target will add an event policy that allows it, and these are exactly the workflows that handle untrusted input with elevated privileges. The default policy also doesn’t apply to private and internal repositories or to workflow_run.
A disconcerting finding is how standard supply chain hardening advice - specifically pinning actions to exact commit SHAs - can inadvertently bypass GitHub’s platform defenses. For example, a “security-hardened” workflow might use actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 (v4.3.0). Because GitHub’s backported protections rely on logic embedded within actions/checkout itself, pinning to SHA values prior to the July 20, 2026 backport release means the workflow runs legacy code without any safety checks. Referencing mutable tags like @v4 (resolving to v4.4.x) or pinned versions such as @v4.4.0 remain protected, whereas older versions like @v4.3.0 or SHA-pinned references to legacy releases offer no protection. To maintain protection, security teams using SHA pinning must ensure their refs are updated to match or exceed the minimum patched release versions: v2.8.0, v3.7.0, v4.4.0, v5.1.0, v6.1.0, or v7.0.0+.
A second gap concerns workflows that bypass actions/checkout altogether. GitHub’s protections are implemented within the action’s code; any alternative method of fetching code operates unrestricted. Direct CLI invocations sidestep protections entirely. For instance, commands like git clone "https://github.com/${PR_REPO}" pr-code && git -C pr-code checkout "${PR_SHA}", gh pr checkout "${PR_NUMBER}", or gh repo clone "${PR_REPO}" fork-code would fetch fork code without actions/checkout’s protections. Third-party checkout actions implement their own git logic, so they don’t inherit these protections. Any of them configured with a PR head ref will check out fork code unrestricted. GitHub’s checkout protections only cover pull_request_target and workflow_run. As stated in the GitHub changelog: ‘Pwn requests triggered in other event types besides pull_request_target (such as issue_comment) will not be blocked by this change. Further hardening of additional events may be explored in future releases.’ This creates an inconsistent security boundary.