CI/CD Pipelines Are Not Isolated: How to Pivot from Repository Access to RCE

TLDR: Researchers at Black Hat 2025 demonstrated that CI/CD platforms like Atlassian Bamboo, GoCD, and OneDev often fail to maintain strict isolation between repository processing and the underlying server. By exploiting vulnerabilities like path traversal, XXE, and environment variable injection, an attacker with low-privileged repository access can achieve full remote code execution on the CI/CD server. Pentesters should prioritize auditing these build-time configurations, as they frequently bypass traditional network-level security controls.

Modern CI/CD pipelines are the crown jewels of the software development lifecycle. They hold the keys to production environments, cloud infrastructure, and the source code itself. Most security teams focus on securing the production environment or the cloud control plane, but they often treat the CI/CD server as a trusted black box. This assumption is dangerous. The research presented at Black Hat 2025 proves that the boundary between a "safe" build worker and the "trusted" CI/CD server is often an illusion.

The Myth of Build Isolation

When you push code to a repository, your CI/CD server clones that code and executes build steps. The standard security model assumes that these build steps run in isolated containers or virtual machines. However, the server-side logic that manages these repositories and build configurations is often riddled with vulnerabilities that allow an attacker to break out of the build environment and compromise the server itself.

The researchers focused on three major platforms: Atlassian Bamboo, GoCD, and OneDev. In each case, they found that the server-side processing of build specifications—like YAML or XML files—was not properly isolated from the file system or the execution environment.

Exploiting Build Specifications

The most effective attack vector involves "poisoning" the build configuration. In Atlassian Bamboo, for example, the "Bamboo Specs" feature allows developers to define their build pipeline as code. The server clones the repository and scans for a specific directory to parse these specifications.

The researchers discovered an arbitrary file read vulnerability by manipulating the bamboo.yml file. By creating a symbolic link named bamboo.yml that points to sensitive files on the server, such as /etc/passwd, they forced the server to read and log the contents of those files during the parsing process. This is a classic path traversal attack, but applied to the build pipeline configuration.

# Create a symbolic link to a sensitive file
ln -s /etc/passwd bamboo.yml

Once the attacker can read arbitrary files, they can often extract credentials, configuration files, or environment variables that lead to further exploitation. In the case of Bamboo, they also found an environment variable injection vulnerability. Because the server uses environment variables to configure connections to external systems like Perforce, an attacker can inject malicious variables. By setting LD_PRELOAD to point to a malicious shared object file, the attacker can hijack the execution flow of the CI/CD server, leading to full remote code execution.

From Repository User to System Admin

For a pentester, the most critical takeaway is the potential for lateral movement. You do not need administrative access to the CI/CD server to start. You only need the ability to commit code to a repository that the CI/CD server monitors.

On platforms like GoCD, the researchers found an XML External Entity (XXE) vulnerability in the configuration repository plugin. By crafting a malicious XML file, they could force the server to perform unauthorized requests or read local files. Furthermore, they identified a privilege escalation path where a regular user could access administrative routes by manipulating the server's internal routing logic, which was built on top of a framework that failed to enforce strict broken access control checks.

During an engagement, your goal should be to identify how the CI/CD server handles build specifications. Look for:

1. Repository-as-Code: Does the server parse YAML/XML files from your repository? If so, can you inject malicious payloads into these files?
2. Build Hooks: Does the platform support Git hooks? If you can write to the hooks directory, you can execute arbitrary commands whenever a push occurs.
3. Shared Runners: Are you using shared runners? If so, can you access the file system of other projects running on the same host?

Securing the Pipeline

Defending against these attacks requires moving away from the "shell-based" runner model. Most CI/CD platforms offer both shell and Docker-based executors. Shell executors are inherently insecure because they share the host's file system and environment.

Always enforce the use of Docker-based runners with strict resource limits and no privileged access to the host. Additionally, treat your CI/CD configuration files as sensitive code. Implement strict code review processes for any changes to build specifications, and ensure that the CI/CD server itself is hardened against the same web vulnerabilities you would look for in any other public-facing application.

The next time you are on a red team engagement, stop looking at the web application and start looking at the CI/CD pipeline that deploys it. You might find that the path to the server is much shorter than you think. The illusion of isolation is exactly that—an illusion. It is time to start treating your build infrastructure with the same level of scrutiny as your production environment.