Anatomy of the JetBrains Cadence Breach: When Unpatched TeamCity Compromised AWS Infrastructure

Modern software delivery pipelines are the engine rooms of enterprise engineering. Every day, they compile millions of lines of source code, run exhaustive test suites, sign container images, and push updates directly to production environments. Because these build systems require sweeping permissions to function—access to source code repositories, package registries, artifact stores, and cloud control planes—they have effectively become the keys to the kingdom.

When attackers want to compromise an organization, they rarely target hardened production firewalls anymore. Instead, they look upstream at the developer tooling, third-party libraries, and orchestration platforms that feed production.

A stark illustration of this shift occurred when attackers successfully breached JetBrains Cadence by exploiting an unpatched vulnerability in their internal TeamCity CI/CD infrastructure. The resulting incident led to the unauthorized extraction of sensitive AWS credentials, demonstrating how a single neglected build server can compromise an entire cloud-native perimeter.

Anatomy of the Breach: Exploiting Unpatched TeamCity

To understand how the JetBrains Cadence breach unfolded, we need to examine the role of enterprise build orchestration tools. JetBrains TeamCity is a popular, feature-rich CI/CD server designed to handle complex build chains, parallel test execution, and multi-platform deployments. Because it sits at the absolute center of the software development lifecycle, it maintains continuous, authenticated network connectivity to version control systems, artifact repositories, and downstream deployment environments.

The vector of compromise in this incident centered on an unpatched security flaw within the TeamCity environment. Historically, build orchestration servers have made attractive targets for remote code execution (RCE) and authentication bypass vulnerabilities due to their immense attack surface. When a TeamCity instance remains unpatched, malicious actors can leverage known exploit chains to bypass administrative authentication controls or inject arbitrary commands directly into the host operating system.

“In a modern microservices architecture, a CI/CD server is essentially a privileged remote execution engine with enterprise-wide reach. Leaving it unpatched is the equivalent of leaving the master keys hanging by the front door.”

Once attackers establish an initial foothold on a build server, they seek persistence. On a CI/CD node, persistence is remarkably easy to maintain. Attackers can plant malicious build steps, modify existing project configurations to silently execute backdoors during routine compilation tasks, or spawn reverse shells disguised as normal build agent processes. This allows them to blend in with standard telemetry and evade casual administrative detection while they map out the internal network and search for valuable secrets.

From Build Server to Cloud: Extracting AWS Credentials

Gaining execution rights on a build server is only the first step. The true value for sophisticated attackers lies in the architectural coupling between modern CI/CD pipelines and cloud environments like Amazon Web Services (AWS).

To build, test, and deploy software at scale, build servers and their executing agents require programmatic access to cloud APIs. However, engineering teams often fall into dangerous storage anti-patterns when configuring this access. Common misconfigurations include:

• Static IAM Keys: Hardcoding long-lived AWS Access Keys and Secret Access Keys directly into CI/CD environment variables or project configuration files.
• Over-Privileged Build Roles: Assigning broad, administrator-level AWS IAM policies to the instance profile hosting the TeamCity server or its worker nodes just to ensure “builds don’t fail.”
• Plaintext Configuration Stores: Storing deployment scripts, .env files, or cloud credentials in unencrypted configuration repositories accessible to anyone with local read access on the server.

During the Cadence breach, once the attackers secured execution privileges on the TeamCity instance, they targeted the local storage mechanisms where cloud credentials were kept. By querying configuration files, environment variable stores, or local metadata services, they successfully extracted sensitive AWS credentials. With these keys in hand, they transitioned effortlessly from an on-premises or hybrid build server to the organization’s cloud infrastructure.

The Cascading Impact: Software Supply Chain Vulnerabilities

The extraction of AWS credentials from a compromised build server triggers a terrifying cascading impact. The blast radius of such an event is rarely contained to a single testing sandbox; instead, it often spans the entire enterprise technology stack.

When attackers obtain administrative or high-level programmatic access to an enterprise cloud account via stolen CI/CD credentials, they gain visibility into proprietary codebases, internal container registries, production databases, and customer data stores. They can quietly provision unauthorized compute resources for cryptomining, exfiltrate intellectual property, or inject malicious payloads directly into outgoing software artifacts.

This incident shares structural DNA with other modern supply chain disruptions where developer tooling and ecosystem components became the primary attack surface. We have seen similar collateral damage in ecosystem-level incidents, such as the alarming workspace compromises explored in Keyv NPM worm AI workspace hijacking, as well as automated data poisoning vectors detailed in the analysis of BDThemes supply chain attack JSON poisoning. Furthermore, as engineering teams increasingly adopt automated coding assistants, the risk surface expands further, echoing the concerns raised when AI writes vulnerabilities in Snowflake Copilot deployments.

When developer tooling—whether it’s an npm package, a build plugin, or a central CI/CD orchestrator like TeamCity—is successfully weaponized, the trust relationship between the vendor, the developer, and the end-user is fundamentally broken.

Hardening the Pipeline: Best Practices for CI/CD Security

Mitigating risks like the JetBrains Cadence breach requires a fundamental shift in how organizations treat their build infrastructure. CI/CD servers must be defended with the same rigor—if not more—as production database clusters.

1. Automated Patch Management and Vulnerability Scanning

Build tooling is a frequent target for zero-day and known vulnerability exploitation. Organizations cannot rely on manual patching cycles for systems that sit at the core of their software delivery network.

• Implement automated vulnerability management software specifically scanning CI/CD components.
• Subscribe to security advisory mailing lists for all orchestration platforms (TeamCity, Jenkins, GitLab CI) to ensure immediate patching upon disclosure.

2. Eliminating Static IAM Keys

The days of storing long-lived AKIA... strings in environment variables must end.

• Transition completely to OpenID Connect (OIDC) federation between your CI/CD provider and cloud environments.
• Use short-lived, ephemeral tokens that are dynamically generated per-build and expire immediately after the build job terminates.

# Example: GitHub Actions or TeamCity OIDC configuration pattern
permissions:
  id-token: write
  contents: read

steps:
  - name: Authenticate to AWS via OIDC
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/CI-CD-Ephemeral-Role
      aws-region: us-east-1

3. Network Segmentation and Least Privilege

Build agents should operate within tightly controlled network zones.

• Isolate CI/CD nodes behind strict firewalls and security groups. They should not have direct, unmonitored access to the wider corporate internet or production data planes.
• Apply the principle of least privilege to build agent roles. If a specific build pipeline only needs to push container images to a single Amazon ECR repository, its IAM policy should restrict its permissions strictly to that action and resource.

Future Outlook: The Evolution of Secure Cloud-Native Delivery

The JetBrains Cadence incident serves as a definitive wake-up call for the DevOps and security communities. As cloud-native architectures grow more complex, the attack vectors targeting software delivery pipelines will only become more sophisticated.

Looking forward, the industry is moving rapidly toward zero-trust build environments. Organizations are beginning to mandate immutable, ephemeral build agents that spin up in isolated micro-VMs for a single task and are immediately destroyed upon completion. This ephemeral model ensures that even if an attacker achieves remote code execution during a build step, their persistence is wiped out the moment the job finishes.

At the same time, security teams are integrating AI-driven anomaly detection directly into CI/CD telemetry pipelines. By baseline-modeling normal build durations, network requests, and API call patterns, security systems can automatically flag and halt pipelines that suddenly attempt unexpected cloud metadata queries or credential exfiltration.

Ultimately, securing the software supply chain requires treating your build server not as an internal utility, but as a critical perimeter asset. By enforcing rigorous patching, abandoning static cloud credentials in favor of OIDC, and isolating CI/CD workloads, engineering organizations can slam the door on the exact vulnerabilities that compromised JetBrains Cadence.