The Illusion of Isolation: Exploiting CI/CD Servers for RCE

For years, security researchers have targeted the CI/CD pipeline, usually focusing on the "Poison Pipeline Execution" (PPE) or supply chain attacks targeting the worker nodes where code is compiled. However, a significant and often overlooked attack surface exists on the CI/CD server itself. In a recent deep-dive presentation at Black Hat Asia 2025, researchers Tian Zhou and his team demonstrated that the mechanisms intended to isolate the server from untrusted user code are often more of an illusion than a reality.

The SCM Attack Surface

The core of the problem lies in how CI/CD servers interact with Source Code Management (SCM) systems like Git, SVN, or Perforce. Because the server must fetch code to scan for configuration files (like bamboo-specs or .onedev-buildspec.yml), it creates a direct channel for an attacker-controlled repository to interact with the server's filesystem and internal processes. This interaction creates three primary attack vectors:

1. User-Controllable Parameters: Repository URLs and branch names are often input by users.
2. Client Interaction: The server uses SCM clients (like the git binary or Perforce clients) which are susceptible to command or parameter injection.
3. Content Control: An attacker can place any file (symbolic links, malicious dynamic libraries, or Git hooks) into the repository that the server eventually clones.

Case Study: Atlassian Bamboo and the "Server Push Attack"

One of the most compelling findings involved Atlassian Bamboo. The researchers discovered that Bamboo's "Configuration as Code" feature (Bamboo Specs) would clone repositories to the local server filesystem for scanning.

The LD_PRELOAD Chain

By finding an environment variable injection in the Perforce repository client, the team aimed for RCE. However, standard environment variable attacks (like BASH_FUNC) are often limited by the OS. To make it universal, they used the LD_PRELOAD technique. To succeed, they needed an absolute path to a malicious .so file on the server. They achieved this by triggering a SnakeYAML exception via a path traversal in an include tag, which leaked the server's temporary checkout directory path. By placing the malicious library in their repo, they could force the server to load it during a Perforce connection test.

The Server Push Attack

Perhaps more innovatively, they introduced the Server Push Attack. Git hooks are scripts that run during certain actions (like pre-receive). Normally, hooks in a cloned repository don't execute on the client. However, by using the file:// protocol, an attacker can trick the server into treating a directory within a cloned repository as a "local" remote. By embedding a "bare repository" inside a standard repository, an attacker can deliver malicious hooks that execute on the Bamboo server when the platform attempts a Git push or merge operation.

GoCD: XXE and Privilege Escalation

In GoCD, the researchers found that the server would parse XML configuration files from a repository. While the documentation didn't explicitly mention XML support for config repos, the underlying plugin architecture supported it, and the parser was vulnerable to XXE (XML External Entity) attacks.

Furthermore, they discovered a critical privilege escalation in GoCD’s JRuby/Rails implementation. Certain administrative handlers were accessible via direct Rails routes without passing through the standard security filters. This allowed a low-privileged user to elevate themselves to an administrator, enabling them to configure "Post-backup scripts"—essentially providing a UI-based path to RCE.

Mitigation and Defense

The research highlights that the server-side components of CI/CD platforms must be treated as highly sensitive. Recommendations for defenders and developers include:

• Mandatory Containerization: All code processing, including initial repository scans and configuration parsing, should occur within isolated, short-lived containers, never on the host server.
• Protocol Restriction: CI/CD servers should strictly whitelist SCM protocols (e.g., only https:// and ssh://), specifically blocking the file:// protocol to prevent Server Push attacks.
• Path Randomization: Using highly randomized, non-predictable paths for repository checkouts can mitigate path-leakage-based attacks.
• Data Isolation: When using shared runners (like GitLab Shell executors), realize that physical isolation is non-existent. Always prefer Docker or Kubernetes-based executors to prevent cross-user data leakage.

Conclusion

The "Illusion of Isolation" serves as a wake-up call for the DevOps community. As we automate more of our infrastructure through code, the tools we use to manage that automation become the ultimate targets. By understanding how these servers process SCM data and internal configurations, security teams can better harden their CI/CD pipelines against the next generation of server-side exploits.