GitHub Actions forked PR risks: are your workflows keeping up?

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

View Full Forum →  |  NHI Foundation Course →