When CI Becomes the Attacker: How Misconfigurations Lead to Full CI/CD Takeover

The Continuous Integration/Continuous Delivery (CI/CD) pipeline is the engine of modern software development, but it's also a high-value target for attackers. Compromising the pipeline provides a direct path to injecting malicious code, stealing sensitive secrets, and achieving lateral movement into the cloud infrastructure.

Modern CI/CD pipelines are designed for speed. Unfortunately, attackers — and sometimes insiders — move even faster.

At Cylent Security, we repeatedly see organizations invest heavily in application security, while their CI/CD systems quietly become the weakest link. A single misconfiguration, an over-privileged workflow, or an unsafe pipeline pattern can turn CI/CD from a delivery engine into an attack platform.

In this post, we share two real-world CI/CD security case studies uncovered during security assessments. Different tools. Different environments. Same outcome: full compromise of the software supply chain.

Case Study #1: From Pull Request to Full GitHub CI/CD Takeover

Overview

During a GitHub Actions security assessment, we identified a critical vulnerability chain that allowed escalation from an unprivileged pull request to:

• Full repository takeover
• Remote Code Execution (RCE) on a private self-hosted runner
• Access to sensitive secrets and internal tokens

The attack followed a clear escalation path, as shown in the diagram:

• Step 1: Unprivileged PR & Privilege Escalation: An attacker submits an unprivileged Pull Request (PR). Because pull_request_target runs with the base repository's permissions, it grants access to a privileged GITHUB_TOKEN, which the attacker's untrusted code could then capture.
• Step 2: Repository Takeover: Using the newly acquired write permissions , the attacker performed an Unauthorized Push. They modified a separate, main-branch workflow —a small change enough to automatically execute on the next run inside the private runner. This converted a harmless PR into a supply-chain attack vector.
• Step 3: Runner RCE and CI/CD Takeover: When the modified main workflow executed on the internal/private runner, the attacker achieved full Remote Code Execution (RCE). This granted them access to environment secrets and internal tokens , and a path for lateral movement inside the organization , ultimately leading to a CI/CD Takeover.

Impact

This vulnerability allowed for a complete supply-chain breach, enabling:

• Repository Takeover : Unauthorized commits and Injection of malicious logic.
• Runner-Level Compromise : Arbitrary command execution , credential exposure , and access to internal systems.

Case Study #2: Poisoned Jenkins Pipeline and Cloud Lateral Movement

Overview

In a Jenkins-based CI/CD environment, we uncovered a critical flaw that allowed a restricted DevOps engineer — with access to only one pipeline — to:

• Escalate privileges inside Jenkins
• Access other teams’ workflows
• Steal cloud credentials
• Pivot into the cloud environment

The attack steps were:

• Step 1: Poisoning the Pipeline: An engineer, who was restricted by RBAC to only one pipeline, was able to modify a shell script within it. This change injected additional logic that would run automatically on execution, creating a foothold for escalating access.
• Step 2: Crossing Workflow Boundaries: The poisoned pipeline leveraged its access to shared resources. This allowed the engineer to interact with files belonging to other teams' pipelines and extract sensitive information , effectively breaking Jenkins' intended job-level separation.
• Step 3: Harvesting Cloud Access: The same pipeline was configured to inject cloud credentials via the Jenkins Credentials Binding plugin. Through the poisoned pipeline, the engineer was able to capture and reuse these credentials.
• Step 4: Lateral Movement into the Cloud: With the harvested cloud credentials now under their control, the engineer expanded the attack beyond Jenkins, gaining unauthorized access to cloud accounts and internal storage or services.

Impact

The incident created multiple high-severity risks and showed how a single insecure pipeline can compromise an entire CI/CD ecosystem, resulting in:

• Breakdown of CI/CD isolation.
• Unauthorized access to additional pipelines.
• Exposure of internal secrets.
• Cloud environment compromise.

A single insecure pipeline compromised the entire CI/CD ecosystem.

The Bigger Picture: CI/CD Is Now a Primary Attack Surface

These two cases share a common lesson:

CI/CD systems are no longer just build tools — they are high-value attack platforms.

Modern pipelines often hold:

• Source code
• Signing keys
• Cloud credentials
• Deployment permissions

When misconfigured, CI/CD becomes the fastest path to full organizational compromise.

Key Takeaways and Mitigation Strategies

These cases underscore two critical and recurring CI/CD security themes: Insufficient Access Controls and Security Misconfigurations.

To protect your software supply chain, we recommend the following expert-led mitigations:

• Enforce the Principle of Least Privilege (PoLP): Credentials and build tokens should have the bare minimum permissions required for the job. For GitHub, explicitly set the permissions block to read-only or none by default and only elevate permissions for specific, necessary steps.
• Strict Access Controls (RBAC): Properly implement and audit Role-Based Access Control to ensure that engineers and automated processes can only access the jobs and resources necessary for their responsibilities.
• Secrets Management: Never hard-code secrets. Use secure vaults and secrets managers and inject them at runtime only when needed.
• Isolate Environments: Do not share workspaces between unrelated CI/CD jobs/pipelines (e.g., in Jenkins). Isolation is key to preventing a breach in one job from cascading to others.
• Handle External Code with Extreme Caution: When using triggers like pull_request_target, never execute untrusted code from a fork in a privileged context. Instead, use the less-privileged pull_request event for external contributions.

How Cylent Security Helps

At Cylent Security, we assess CI/CD environments the way attackers do:

• GitHub Actions, GitLab CI, Jenkins, CircleCI, Bitbucket
• Workflow logic, permissions, and trust boundaries
• Runner and agent security
• Secret handling and credential exposure
• Supply-chain attack paths

We don’t just scan pipelines — we break them safely to show real impact.

Want to Know If Your CI/CD Can Be Abused?

If you’re relying on CI/CD to ship production code, you’re already trusting it with your crown jewels.