The Pwn Request Reckoning: What Still Works Against GitHub Actions

GitHub's 2026 security updates to Actions have materially raised the bar for pull_request_target based repository compromise, but the platform has not eliminated the root design flaw. The infamous pwn request — where a malicious pull request triggers privileged workflow execution — remains exploitable in specific configurations, especially in repositories that process untrusted code with secrets in scope.

Security teams maintaining public or hybrid repositories need to audit immediately. The residual attack surface is smaller, but the consequences — credential theft, supply-chain injection, and persistent access to source code — are unchanged. This post breaks down what still works, how to detect it, and how to harden your pipelines.

Technical Analysis

Affected Products and Platforms

• GitHub Actions workflows using pull_request_target
• Public repositories and private repositories with external contributors
• Self-hosted runners exposed to fork PRs
• Any workflow that checks out PR code and then executes it (build, test, lint, format)

What Is a Pwn Request?

A pwn request occurs when a workflow triggered by pull_request_target runs in the base repository context with access to GITHUB_TOKEN and repository secrets, but checks out or evaluates attacker-controlled code from a fork. The attacker opens a PR from a fork, modifies the workflow or a script it invokes, and gains code execution inside a privileged context.

GitHub's 2026 Changes

GitHub has introduced additional safeguards, including improved default permissions for pull_request_target, enhanced warnings on risky patterns, and tighter controls around environment protection rules. However, these mitigations are opt-in or incomplete:

• pull_request_target still grants write access to the base repo and access to secrets by default unless explicitly restricted.
• Workflows that run actions/checkout on the PR head and then execute build/test scripts remain exposed.
• Self-hosted runners and reusable workflows can bypass some platform-level restrictions.

Exploitation Status

This is not a single CVE; it is a persistent design weakness. Exploitation is well documented in the wild, and GitHub's 2026 changes acknowledge that attacks continue. There is no public CISA KEV entry for the pattern because it is a configuration flaw rather than a vendor vulnerability, but multiple high-profile supply-chain incidents have used this technique.

Detection & Response

Sigma Rules

---
title: GitHub Actions Pull Request Target Privileged Checkout
id: 550d9a23-0f72-4e3a-a8c5-1d2f3b4c5d6e
status: experimental
description: Detects workflows using pull_request_target combined with checkout of untrusted PR code.
references:
  - https://www.wiz.io/blog/github-actions-security-pwn-request-reckoning
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1195
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '.github/workflows/'
    Contents|contains:
      - 'pull_request_target'
      - 'actions/checkout'
  condition: selection
falsepositives:
  - Legitimate workflows that do not execute PR code after checkout
level: high
---
title: GitHub Actions Secrets Access from Pull Request Target
id: 7a3f1c82-9e4b-4d67-bc12-3e5a8f901234
status: experimental
description: Detects pull_request_target workflows that reference secrets or GITHUB_TOKEN with write permissions.
references:
  - https://www.wiz.io/blog/github-actions-security-pwn-request-reckoning
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1552
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '.github/workflows/'
    Contents|contains:
      - 'pull_request_target'
      - 'secrets.'
  selection_token:
    TargetFilename|contains:
      - '.github/workflows/'
    Contents|contains:
      - 'pull_request_target'
      - 'GITHUB_TOKEN'
      - 'permissions: write'
  condition: selection or selection_token
falsepositives:
  - Workflows that only trigger labels or comments without code execution
level: high

KQL (Microsoft Sentinel / Defender)

// Hunt for GitHub Actions workflow files using pull_request_target with checkout and secrets
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor == "GitHub"
| where DeviceProduct == "Actions"
| where Message has "pull_request_target"
| where Message has "actions/checkout" or Message has "secrets."
| project TimeGenerated, SourceIP, SourceUserID, Message, FilePath
| order by TimeGenerated desc

Velociraptor VQL

-- Hunt for GitHub Actions workflow files that use pull_request_target and checkout PR code
SELECT FullPath, Btime, Mtime, Size, Data as Content
FROM glob(globs="**/.github/workflows/*.yml")
WHERE Content =~ "pull_request_target"
  AND Content =~ "actions/checkout"

Remediation Script

#!/usr/bin/env bash
# Audit GitHub Actions workflows for pull_request_target combined with checkout and secrets

set -euo pipefail

REPO_PATH="${1:-.}"

if [ ! -d "$REPO_PATH/.github/workflows" ]; then
  echo "No .github/workflows directory found in $REPO_PATH"
  exit 0
fi

echo "Scanning workflows in $REPO_PATH/.github/workflows ..."

find "$REPO_PATH/.github/workflows" -type f \( -name '*.yml' -o -name '*.yaml' \) | while read -r file; do
  if grep -q 'pull_request_target' "$file" && grep -q 'actions/checkout' "$file"; then
    echo "[RISK] $file uses pull_request_target with checkout"
    grep -nE 'pull_request_target|actions/checkout|secrets\.|GITHUB_TOKEN|permissions:' "$file" || true
    echo ""
  fi
done

# Optional: enforce read-only permissions by default
echo "Recommendation: set top-level permissions to contents:read and require manual approval for workflows from forks."

Remediation

1. Avoid pull_request_target unless absolutely necessary. Use pull_request with explicit permissions and require approval for first-time contributors.
2. If you must use pull_request_target, never check out PR code. Instead, inspect metadata only, or use a two-workflow pattern where a privileged workflow triggers an unprivileged one.
3. Set permissions explicitly at the workflow level:
   • contents: read
   • pull-requests: write only if needed
   • Disable id-token: write unless required
4. Use GitHub's "Require approval for first-time contributors" and "Require approval for all outside collaborators" settings.
5. For self-hosted runners, isolate fork PRs to ephemeral, network-segmented runners with no secrets.
6. Rotate any secrets exposed to pull_request_target workflows, and audit workflow run logs for suspicious activity.
7. Review GitHub's official guidance and the Wiz advisory for additional hardening recommendations.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub