pull_request_nightmare Part 1: Exploiting GitHub Actions for RCE and Supply Chain Attacks

Executive Summary:

• The Orca Research Pod has uncovered critical security risks across several high-profile open source repositories that relied on GitHub Actions.
• By abusing misconfigured workflows triggered via pull_request_target, adversaries could escalate from an untrusted forked pull request into remote code execution (RCE) on GitHub-hosted or even self-hosted runners.
• We investigated and exploited projects maintained by Google, Microsoft, and other Fortune-500 companies. Each contained insecure workflows that allowed attackers to:
  • Run arbitrary code on Actions runners
  • Exfiltrate sensitive secrets such as API keys
  • Push malicious code or dependencies to trusted branches
  • Abuse overly permissive GitHub tokens for package uploads, PR manipulation, and branch control
• These flaws highlight the systemic risk of misconfigured CI/CD pipelines: a single forked pull request can become a supply chain compromise.
• We’ve reported our findings to the affected organizations via a responsible disclosure.

What is pull_request_target?

GitHub Actions offers multiple triggers for running workflows. The pull_request_target trigger is often misunderstood and misused. Unlike pull_request, which runs workflows in the context of the forked branch with limited permissions, pull_request_target runs workflows in the context of the base repository, where secrets are exposed and the provided GITHUB_TOKEN typically has both read and write permissions by default. Not only that, but pull_request_target workflows run without requiring manual approval unless a repository is explicitly configured to enforce it. This trigger was intended for safe tasks like triage and labeling; however, if workflows pull and execute untrusted code from a pull request, the base repo permissions and secrets can be abused.

name: Labeler
on: [pull_request_target]

jobs:
  label:

    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
    - uses: actions/labeler@v4
      with:
        repo-token: "${{ secrets.GITHUB_TOKEN }}"

Above is a very well-known and common use-case on GitHub. It looks at the files changed in a pull request and applies labels back onto the PR. pull_request_target is required here because labeling needs write access to the base repository’s PR metadata. The plain pull_request event cannot grant those permissions for PRs from forks, so the labeler would not work.

Executing Untrusted Code in CI/CD

The main issue that made these exploits possible was that workflows were checking out and executing code directly from untrusted pull requests. Once attacker-controlled code runs in the context of a privileged GitHub Actions job, every other misconfiguration becomes exploitable, from token misuse to secret exposure. Let’s walk through a simple example.

name: Dangerous PR runner
on:
  pull_request_target:

jobs:
  run-pr-code:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - name: Run script
        run: |
         scripts/run.sh

This workflow checks out untrusted PR code and runs it under pull_request_target, where the job has write permissions to the repository. Because it executes attacker-controlled code with the base repo’s token, an attacker could execute code on a privileged GitHub runner and push commits, alter workflows, or steal sensitive data.

Throughout our analysis, we had managed to identify and exploit recurring mistakes that could expose organizations to serious security risks:

1. Write-enabled tokens: misconfigured workflows granting untrusted contributors the ability to push code back to the repository.
2. Secrets Exposed: sensitive keys and tokens that are embedded into misconfigured workflows, allowing easy exfiltration and compromise.
3. Self-hosted runners: powerful cloud machines were made available to external contributors, via a misconfigured, auto-approved workflow.
4. Legacy tokens without fine-grained permissions: older repositories relied on broad-scope tokens created before GitHub’s 2021 security improvements.

While the specific impact varied by project, the underlying risk was the same: running untrusted code with too much privilege.

Finding Vulnerabilities in the Wild

During our research, we found that these issues are not just theoretical. Multiple high-profile repositories across different organizations were vulnerable to the same core mistake of running untrusted PR code in privileged workflows. In some cases, this exposed sensitive API keys, in others it gave us the ability to push code back into official branches (including main) , and in a few, it opened the door to abusing cloud resources behind the scenes.

Launching September 30, Part 2 takes you behind the scenes, into real incidents where a single misconfigured workflow turned into a full-blown compromise. We present in-the-wild, deep-dive examples that follow the attacker step by step and highlight the subtle mistakes defenders missed. From secret exposure to privilege escalation, you will see how seemingly harmless gaps in workflows become catastrophic failures when chained together. If you want to understand how attackers exploit the very pipelines teams rely on, this is the follow-up you cannot afford to miss.

How Can Orca Help?

The Orca Cloud Security Platform provides comprehensive Application Security (AppSec) capabilities. With Orca, organizations can: 

• Audit repositories and workflows for misconfigurations: Orca continuously scans SCM platforms like GitHub for overly permissive tokens, outdated workflows, and missing security guardrails. This helps ensure legacy repositories and pipelines are brought up to least-privilege standards. 
• Detect and prevent secret exposure: Orca provides comprehensive and advanced Secret Detection capabilities that integrate with your SCM repositories, scan every push or pull request for secrets, and provide flexible guardrails that can prevent secrets from being exposed. 
• Set policy guardrails that block unsafe deployments: Orca enforces policies across the development pipeline to ensure that misconfigurations, vulnerabilities, and secrets are caught early and never reach production. 
• Connect cloud to development: Orca’s Cloud-to-Dev capabilities enable you to trace cloud risks to their origins in source code and remediate issues at their source. 

Learn more 

Interested in learning more about the Orca Platform? Schedule a personalized 1:1 demo.