Why does a forked pull request become dangerous in GitHub Actions?

Why forked pull requests are dangerous in GitHub Actions

A fork becomes dangerous when the workflow treats untrusted code as if it were trusted repository code. The key problem is not the fork itself, but the moment a job executes attacker-controlled content while still holding repository context, permissions, or credentials that were meant only for trusted branches and maintainers.

That risk is amplified in GitHub Actions because a workflow can combine code execution, token access, secret access, artifact upload, and repository write operations in the same run. If those privileges are present before the workflow has reduced trust, a pull request from a fork can cross from review activity into secret exposure or repository tampering.

For a practical example of this failure mode, NHIMG’s GitHub and GitHub Actions Security Guide covers the common controls that separate untrusted pull request handling from privileged workflow execution, including token scope, action pinning, runner hardening, and workflow injection paths.

Where the trust boundary breaks down

The dangerous part is usually the sequence, not a single setting. A workflow may check out PR code, run scripts from the repository, or load composite and third-party actions before it has constrained permissions. At that point, an attacker can make the pipeline do work on their behalf, and any secrets, tokens, or write-capable automation identity available to the job become part of the attack surface.

That is why forked pull requests are a classic poisoned pipeline pattern. The attacker does not need direct repository access if the workflow itself will fetch dependencies, execute build steps, or expose environment data under the base repository's authority.

One documented illustration is Travis CI secrets exposure 2021, where forked pull requests were able to reach signing keys, API tokens, and other credentials because the build context was more permissive than the source of the code deserved.

How to contain untrusted pull request execution

The safe pattern is to treat forked PRs as untrusted until proven otherwise. That means limiting the default token, removing write permissions, withholding secrets, and making any step that handles code or dependencies run with the smallest possible authority. If a workflow must inspect fork content, it should do so before privileged actions are enabled and with explicit controls around what can be read or executed.

Where the workflow exists to verify changes, use a design that separates validation from release. Validation should answer whether the code is safe; it should not also be the point where credentials for deployment, publishing, or repository administration are present. This is especially important when the same pipeline also handles package publication, deployment keys, or signing material.

NHIMG’s CI/CD Pipeline Identity Security Guide is useful here because it focuses on keyless federation, token permissions, pinned actions, and trusted publishing patterns that reduce the blast radius of untrusted builds.

Risk and Threat Considerations

Forked PR abuse becomes high impact when the workflow can read secrets, mint tokens, or perform writes before trust is reduced. The attacker objective is usually credential theft, repository compromise, or downstream supply-chain abuse through a poisoned build or release path.

Failure mechanism: An untrusted PR is executed in a context that still has repository secrets, broad token scopes, or mutable permissions, allowing attacker-controlled code to exfiltrate material or alter the repo and build outputs.

Impact: The result can be secret leakage, malicious commits, tampered releases, compromised automation, or follow-on attacks against downstream consumers that trust the pipeline output.

Practitioner Guidance

What to verify: Confirm that forked pull request runs receive the minimum token scope, no privileged secrets by default, and no write-capable credentials unless a separate, explicitly trusted workflow step grants them.

Decision rule: If a workflow must execute code from a fork, treat every step before privilege reduction as hostile execution. If the job needs secrets or write access, move that capability into a separate gated path rather than broadening the PR job.

What good looks like: A forked PR can validate, lint, or test changes, but it cannot reach deployment tokens, signing keys, or repository write permissions unless a maintainer explicitly promotes the change through a controlled path.

Practitioner takeaway: The real boundary in GitHub Actions is not “trusted repo versus fork”, but “untrusted code versus privileged execution context”; once those are combined, compromise becomes a workflow design problem, not just a permissions problem.

Related resources from NHI Mgmt Group

• How should security teams stop forked pull requests from reaching privileged GitHub Actions jobs?
• What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
• What breaks when GitHub Actions workflows trust attacker controlled branch names or pull request metadata?
• How should security teams harden GitHub Actions against untrusted pull request content?