Topic starter
11/06/2026 11:37 pm
TL;DR: Misconfigured GitHub Actions workflows triggered by pull_request_target let untrusted forked pull requests run in the base repository context, exposing secrets, write-enabled tokens, and even self-hosted runners, according to Orca Security. The control failure is not CI/CD itself but the assumption that privileged workflow contexts can safely execute untrusted code.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “pull_request_nightmare Part 1: Exploiting GitHub Actions for RCE and Supply Chain Attacks”.
Key questions
Q: What breaks when pull_request_target workflows process untrusted input?
A: The workflow can turn attacker-controlled text or branch names into executable shell syntax while still running with the base repository's permissions.
Q: Why do fork based pull request workflows increase supply chain risk in cloud native development?
A: Because a fork can carry malicious workflow files, scripts, or package metadata that are later executed in the context of the upstream repository.
Q: What do teams get wrong about securing GitHub Actions with token permissions?
A: A common mistake is treating workflow security as a one-time setting instead of a per-action requirement.
Practitioner guidance
- Audit every pull_request_target workflow Identify any workflow that combines pull_request_target with checkout or execution of forked code, then classify it as privileged until proven otherwise.
- Separate triage from execution Keep labeling, commenting, and metadata updates in one workflow, and move build or test execution for forked code into a separate unprivileged path.
- Restrict token permissions by default Set GITHUB_TOKEN to the minimum permissions required for each workflow and remove write access from jobs that do not need to change repository state.
Bottom line: Misused pull_request_target workflows can turn a forked pull request into privileged code execution on GitHub-hosted or self-hosted runners.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 8:21 am
Privileged CI/CD context is an identity boundary, not a convenience setting. pull_request_target shifts trust from the fork to the base repository, which means the workflow is acting with repository identity and associated authority. Once teams forget that the workflow itself is privileged, they create a path where untrusted code inherits trust by execution order rather than by approval. Practitioners need to treat workflow triggers as part of access governance, not just build orchestration.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: How should teams separate safe PR automation from privileged execution?
A: Use one workflow for non-execution tasks such as labeling and a different, tightly controlled workflow for tests or builds. The privileged path should not execute forked code until trust is explicitly established, because workflow order determines whether the job behaves like inspection or like remote code execution.
👉 Read our full editorial: GitHub Actions pull_request_target misuse turns forks into RCE
This post was modified 2 days ago by NHI Mgmt Group