Notifications
Clear all
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.
NHIMG editorial — based on content published by Orca Security: GitHub Actions pull_request_target misuse and supply chain risk
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes
Questions worth separating out
Q: How should security teams handle forked pull requests in GitHub Actions?
A: Security teams should assume forked pull requests are untrusted until proven otherwise.
Q: Why do pull_request_target workflows create more risk than standard pull request workflows?
A: pull_request_target runs in the base repository context, which can expose secrets and write-enabled tokens to code that came from a fork.
Q: What breaks when CI/CD workflows can run untrusted code with privileged tokens?
A: The trust boundary breaks.
Practitioner guidance
- Harden pull_request_target usage Allow pull_request_target only for metadata workflows that never check out or execute pull request code.
- Separate untrusted contributions from privileged jobs Route forked pull requests into isolated workflows with read-only permissions and no secret access.
- Reduce token scope and secret visibility Replace broad repository tokens with narrowly scoped permissions, and ensure secrets are injected only into jobs that genuinely require them.
What's in the full article
Orca Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of unsafe GitHub Actions workflow patterns and how they were exploited in practice
- Specific workflow snippets showing where pull_request_target becomes dangerous when paired with code checkout
- The practical differences between GitHub-hosted and self-hosted runners in privileged contribution flows
- The vendor's disclosure and follow-up context for the affected repositories
👉 Read Orca Security's research on GitHub Actions pull_request_target abuse →
GitHub Actions forked PR risks: are your workflows keeping up?
Explore further
12/06/2026 8:21 am
GitHub Actions workflow identities must be governed like privileged NHIs, not treated as incidental automation. The article shows that a repository token, a self-hosted runner, and a secrets-bearing job together function as an identity stack with real blast radius. When that stack is reachable from untrusted pull request content, the issue is not just misconfiguration but over-trusted non-human access. Practitioners should treat workflow identities as first-class governed assets.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who should own GitHub Actions workflow governance in an enterprise?
A: Ownership should be shared across security, IAM, platform engineering, and application teams. Security defines the control baseline, IAM governs token scope and lifecycle, platform teams standardise runner and workflow patterns, and application owners approve the exceptions tied to their repositories.
👉 Read our full editorial: GitHub Actions pull_request_target misuse turns forks into RCE
