What breaks when a GitHub Actions workflow can run attacker-controlled code from a pull request

How the privilege boundary fails in GitHub Actions

The core break is not just “untrusted code ran,” but that the workflow treated pull request content as if it were still inside the trusted build boundary. Once attacker-controlled code can reach steps that have write tokens, secrets, or deployment permissions, the workflow stops being a review-only process and becomes an execution path with authority.

That matters because GitHub Actions is often used as part of a release pipeline, where the workflow can read repository contents, publish artifacts, sign outputs, or reach external services. If the pull request can influence that execution while the job still holds privileged material, the boundary between code review and trusted automation no longer exists.

A safe workflow design assumes that untrusted contributions and trusted credentials do not meet in the same execution context. When they do, the workflow itself becomes the control plane being attacked, not just the application code under review.

Why attacker-controlled pull request code is dangerous

Once untrusted code runs in a privileged workflow, the attacker can target the exact material that makes CI valuable: repository secrets, cloud credentials, package publishing tokens, signing keys, and deployment credentials. That turns a normal pull request into a potential secret-exposure event and, in some cases, a supply chain entry point.

The most damaging outcome is often not immediate defacement but silent abuse. A malicious step can print secrets to logs, alter build outputs, exfiltrate tokens, or prepare later access by changing workflow files, release artifacts, or dependency references.

This pattern is especially dangerous because the code may look harmless in review while the actual compromise happens only after the workflow runner starts executing. The risk is therefore a trust-boundary failure, not simply a code-quality issue.

What organisations should check in their pipelines

Teams should first determine whether any workflow triggered by a pull request can access secrets, write to the repository, publish packages, or authenticate to cloud services. If the answer is yes, the workflow deserves the same scrutiny as any other privileged production system.

It also helps to review which events, branches, and approval paths can reach privileged jobs. A workflow that is safe on a protected branch may still be unsafe if it can be triggered by forked pull requests, reusable workflow calls, or indirect dispatch paths that inherit trust from elsewhere in the pipeline.

Finally, organisations should inspect whether the workflow depends on long-lived credentials or broad default permissions. The less a job can do by default, the less useful it is to an attacker who manages to steer execution.

Containment, detection, and recovery after exposure

If attacker-controlled code has run with privileged access, treat the event as potential credential compromise until proven otherwise. The immediate response is to identify which secrets, tokens, keys, and deployment credentials were available to the job, then revoke or rotate the ones that could have been copied or abused.

Detection should focus on the runner and the surrounding control plane: unusual log output, unexpected network destinations, new workflow files, altered release artifacts, or signs that the job accessed resources outside its normal purpose. Post-patch review should also check for persistence, because an attacker may have left behind workflow changes or backdoored dependencies rather than just stealing a secret.

Recovery is not complete when the workflow stops running. Any artifact, package, token, or environment the job could touch should be reviewed for unauthorized modification or downstream reuse.

Risk and Threat Considerations

A privileged pull request workflow creates a direct path from untrusted input to trusted execution. That makes it attractive for secret theft, release tampering, and supply chain abuse, especially when the job can reach publishing credentials or cloud access.

Failure mechanism: The attacker shapes code that the workflow executes under trusted authority, then uses that context to read secrets, alter build steps, or exfiltrate tokens before defenders notice.

Impact: The result can include repository compromise, poisoned releases, unauthorized cloud actions, exposed CI/CD secrets, and follow-on access through stolen credentials.

Practitioner Guidance

What to watch for: Separate untrusted pull request execution from privileged release tasks. If a workflow must test contributor code, it should do so without exposing secrets or write-capable credentials to that execution path.

Governance implication: Treat workflow permissions, secret exposure, and event triggers as security controls with owners, not as developer convenience settings. The control decision is whether the pipeline can ever let untrusted code meet trusted authority in the same run.

Practitioner takeaway: The safest assumption is that any pull request should be able to influence code paths, but never the credentials that can publish, deploy, or trust that code.

Related resources from NHI Mgmt Group

• 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?
• What fails when GitHub Actions workflows can be modified to run attacker-controlled code?
• What breaks when a GitHub Actions workflow with pull_request_target can reach publish secrets?