GitHub Actions Protections Leave Several Pwn Request Attack Paths Open

Summary
GitHub’s 2026 protections make common Pwn requests harder, but older checkout versions, unprotected triggers, script injection, artifact poisoning, and persistent runner state leave attack paths open. The article explains the risks and recommends workflow audits and key
Key points
- GitHub added fork-checkout protections, read-only cache tokens, and event policies. A default policy blocking pull_request_target in public repositories without an explicit policy is scheduled for December 2, 2026.
- Older SHA-pinned actions/checkout versions may lack backported protections; custom checkout scripts, third-party checkout actions, and the allow-unsafe-pr-checkout option can also bypass them.
- Untrusted pull request data interpolated directly into shell commands can enable code execution with workflow secrets, even when the workflow does not check out fork code.
- issue_comment and repository_dispatch workflows can remain exploitable when they use attacker-influenced checkout refs; the article recommends verifying permissions, pinning the approved commit, and validating inputs.
- A privileged workflow_run job can execute attacker-controlled artifacts uploaded by an unprivileged pull_request workflow; cache-token protections do not cover artifacts.
- Non-ephemeral self-hosted runners can retain attacker-controlled files or tools between jobs. The article recommends ephemeral runners and separating trusted and untrusted workflows.
- The external-contributor approval setting does not gate pull_request_target runs; the article recommends required-reviewer environments or actor rules for privileged jobs.
Article Details
- Attack Vectors
- A pull_request_target workflow can process fork pull requests with repository secrets or write-capable tokens; older SHA-pinned actions/checkout versions may lack later fork-checkout protections.
- Custom checkout scripts, direct Git or GitHub CLI commands, and third-party checkout actions can fetch attacker-controlled fork code without actions/checkout's protections.
- Privileged workflows triggered by issue_comment or repository_dispatch may check out attacker-influenced refs or payload-selected code without checkout protections.
- Untrusted pull-request data interpolated into shell commands can cause script injection and command execution, even when the workflow does not check out fork code.
- A pull_request workflow can upload attacker-controlled artifacts that a privileged workflow_run later downloads and executes.
- Code running on a non-ephemeral self-hosted runner can poison persistent files, caches, build directories, or installed tools used by a later trusted job.
- Enabling allow-unsafe-pr-checkout explicitly reopens the untrusted fork-code checkout path.
- Defensive Notes
- Update SHA-pinned actions/checkout references to patched releases: v2.8.0, v3.7.0, v4.4.0, v5.1.0, v6.1.0, or v7.0.0 and later.
- Audit workflow triggers, checkout methods, action versions, artifact handling, self-hosted runners, and allow-unsafe-pr-checkout usage.
- For comment- or dispatch-triggered workflows, verify the triggering user's current repository permission and restrict who can send repository_dispatch events; do not treat the event payload as proof of sender identity.
- Check out the exact approved pull-request head SHA and abort if the pull request changes after approval; validate event arguments and payload fields against a strict allowlist.
- Pass untrusted values to shell commands through environment variables, not direct expression interpolation, and quote shell variable expansions.
- Treat artifacts from less-trusted runs as untrusted data; do not execute them in privileged workflows.
- Use ephemeral runners for workflows reachable from untrusted events, and separate untrusted and trusted workflows into different runner groups.
- For workflows that require pull_request_target, use an explicit event policy and restrict it to audited workflow files; place privileged jobs behind required reviewers or actor rules where appropriate.
MITRE ATT&CK
Vendors
GitHubwith 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..WizWiz Code automatically scans GitHub Actions workflows for Pwn requests, script injection, version gaps, and risky configurations to cover this residual attack surface. Alternatively, use open-source tools like zizmor or
Products
actions/checkoutJune 18, 2026 Release of actions/[email protected], blocking fork code checkouts by default in untrusted triggers (pull_request_target, and workflow_run triggered by pull requests).GitHub ActionsIn Part 1 of our GitHub Actions research, we laid out the threat model and core defenses, and Part 2 covered AI-powered actions. This post updates that threat model for 2026: what GitHub's changes actually protectWiz CodeWiz Code automatically scans GitHub Actions workflows for Pwn requests, script injection, version gaps, and risky configurations to cover this residual attack surface. Alternatively, use open-source tools like zizmor or
