Skip to content

Back to the catalog

PWN Request Threat: A Hidden Danger in GitHub Actions | Endor Labs
endorlabs.comarticle

PWN Request Threat: A Hidden Danger in GitHub Actions | Endor Labs

Explains the "pwn request" weakness in GitHub Actions. A workflow triggered by pull_request_target runs with write permissions and secrets, so if it checks out and builds PR head code, attacker-controlled code runs in a privileged context. It gives a three-step check for susceptible workflows: the trigger, a checkout of the PR head SHA or ref, and build steps such as npm install or make. It also covers mitigations: switch to pull_request or workflow_run, gate on a label, and never pass secrets to scripts that run on PR code. It notes safe patterns and cites the puppetlabs finding.

TL;DR Explainer on pwn requests: pull_request_target plus a checkout of PR head code and a build step gives attackers write access and secrets in GitHub Actions. Includes detection steps and fixes.
Open original ↗
Document

What it is

Endor Labs' description of the "PWN request" weakness in GitHub Actions. A pull_request_target workflow gets write permission and repository secrets, and it becomes exploitable when it checks out and runs code from the PR. The page cites a PWN vulnerability found in puppetlabs but gives no CVE or other details.

Preconditions / Affected

The page says a workflow is susceptible when all three hold:

flowchart LR
  A[Trigger is pull_request_target] --> D{All three?}
  B[PR code checked out] --> D
  C[Build or script runs on it] --> D
  D -->|yes| E[Attacker code runs with write token and secrets]
  D -->|no| F[Not this pattern]

Strings the page lists as signs of a PR checkout (step 2):

  • actions/checkout@
  • "${{ github.event.pull_request.head.sha }}"
  • "refs/pull/${{ github.event.issue.number }}/head"

The last ref uses issue.number, which points to comment-driven workflows. The page says Endor's scanner also examines issue_comment triggers, not only pull_request_target. It also follows workflows called by parent workflows, so a risky pattern in a called workflow still counts.

Step 3 is any build step that interacts with the checked-out code: npm install, make, custom scripts or other tools.

What to do

  • If the workflow needs neither write access nor secrets, use pull_request instead.
  • Grant privileges only where needed, using pull_request and workflow_run.
  • Gate pull_request_target on a specific label. The label signals that someone with write access has vetted the PR.
  • Never pass credentials to custom scripts that run on checked-out PR code.
  • Avoid checking out PR code and then running build commands on it.

The page names three patterns where combining pull_request_target with a PR checkout can be safe, because the PR code is not executed:

  • Reformatting and committing code.
  • Generating a diff by checking out both the base and head repositories.
  • Running grep over the checked-out source.

Caveats

  • pull_request runs from a same-repo branch also get write permission and secrets. Only external forks lack them, so the safe default depends on where the PR comes from.
  • The page's closing advice to review repository contribution and merge controls is not elaborated.
  • Roughly the last third of the page is a pitch for Endor Labs' scanner.

Technologies named here

Techniques named here

Related in DevSecOps