JetBrains Cadence Breach Exposed AWS Credentials After TeamCity RCE Exploitation

JetBrains has disclosed a breach of its Cadence cloud computing service after unidentified attackers exploited CVE-2026-63077, a critical remote-code-execution vulnerability in TeamCity.

The intrusion affected the Cadence server at api.cadence.jetbrains.com, which JetBrains has taken offline. Attackers accessed a server backup, extracted AWS identity credentials, and reached files stored in S3 buckets associated with the service.

JetBrains identified the exploitation on August 23, 2026. The broader intrusion window ran from August 8 through August 24, 2026, and activity from August 8 onward should be treated as potentially suspicious.

The company said the TeamCity server should have received an update through its vulnerability-response process. It has not explained why the patch was not applied.

An Unpatched TeamCity Server Opened the Door

CVE-2026-63077 is an unauthenticated remote-code-execution flaw in JetBrains TeamCity’s agent polling protocol. It is categorized as CWE-502, deserialization of untrusted data.

An attacker able to reach a vulnerable TeamCity server can exploit the issue without credentials or user interaction. Successful exploitation permits arbitrary operating-system command execution with the privileges assigned to the TeamCity server process.

The vulnerability has a CVSS v3 score of 9.8 and the vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That rating reflects a network-accessible attack requiring low complexity, no existing privileges, and no action from a legitimate user. A successful compromise can have high confidentiality, integrity, and availability impacts.

The affected version boundaries cover two TeamCity release branches. Deployments earlier than 2025.11.7 are affected, while the NVD description also identifies versions before 2026.1.3 and 2025.11.7 as vulnerable. Administrators should therefore use the appropriate fixed release for their installed branch rather than treating 2025.11.7 as a universal version boundary.

JetBrains has not disclosed the exact TeamCity version installed on the compromised Cadence server. It has only characterized the deployment as unpatched.

CISA Had Already Confirmed Active Exploitation

CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog on August 5, 2026. The remediation deadline for U.S. federal agencies was August 8, 2026—the same date on which the reported Cadence intrusion window began.

Inclusion in the KEV catalog means the vulnerability was not merely considered exploitable in theory. CISA had evidence of exploitation in real-world attacks.

The agency requires organizations within scope to apply vendor mitigations while following BOD 26-04, “Prioritizing Security Updates Based on Risk,” and its Forensics Triage Requirements. For cloud services, agencies must follow the applicable BOD 26-04 guidance or discontinue using the product when mitigations are unavailable.

CISA also directs stakeholders to evaluate each asset’s internet exposure and ensure that patching follows the binding directive. Internet-reachable TeamCity systems warrant particular scrutiny because CVE-2026-63077 does not require authentication.

The Cadence incident shows the operational consequences of leaving such a server exposed. Initial code execution on a development platform gave the attackers access to stored secrets that could be used against cloud infrastructure and external services.

Backup Data Led Attackers to AWS Identities and S3 Files

Cadence is a JetBrains-hosted service that connects to PyCharm through an optional plugin. Developers can use it to run machine-learning workloads and other resource-intensive jobs on cloud GPUs from within the IDE.

After compromising the Cadence server, the attackers accessed a full server backup from 2024. That backup could contain credentials, secrets, configuration information, execution or build artifacts, logs, and other operational data.

JetBrains confirmed that multiple AWS IAM users and their associated credentials or secrets were extracted from the backup. The affected identities included accounts belonging to JetBrains employees who had used Cadence.

The attackers also accessed files in S3 buckets within JetBrains AWS accounts used by the service. Potentially exposed storage may contain data associated with current Cadence users, including:

• Usernames, real names, and email addresses
• Last-login timestamps and last-accessed IP addresses
• PyCharm project source code
• Credentials and configuration data
• Execution inputs, outputs, and artifacts
• Other files uploaded or synchronized for cloud processing

Developers may have transferred more than the files deliberately selected for execution. Source trees often contain environment files, deployment configuration, API keys, repository metadata, or credentials embedded in scripts and notebooks.

JetBrains said its investigation found no additional affected users beyond those contacted directly. Nevertheless, it is treating data held in the relevant storage as potentially exposed.

The company has also warned that every Cadence execution, including its inputs and outputs, should be considered untrusted. That expands the response beyond confidentiality: organizations must verify that artifacts produced through the compromised environment were not altered.

Indicators Point to Six Exploitation Addresses

JetBrains associated six IP addresses with observed exploitation activity:

150.109.230.104
43.153.227.206
62.210.127.48
210.247.242.190
15.235.225.205
152.233.30.18

Defenders should search authentication, cloud, repository, endpoint, and network records for these addresses. Matches are particularly significant when they involve credentials stored in Cadence or systems accessible through those credentials.

The investigation should not rely solely on this list. Attackers can change infrastructure, route traffic through other hosts, or use stolen credentials from unrelated locations.

Teams should review activity during and after the intrusion window for unexpected repository clones, downloads, commits, or changes to secrets and webhooks. Newly created personal access tokens, API tokens, SSH keys, collaborators, service accounts, and altered permissions also require investigation.

Cloud logs should be checked for changes to IAM roles, policies, trust relationships, and storage permissions. Unusual access to AWS S3 objects or equivalent Google Cloud storage may indicate that exposed credentials were used beyond JetBrains’ environment.

Software supply-chain systems are another priority. Organizations should look for unauthorized package publication, modified releases, altered container images, or changes to build and deployment workflows.

The attackers have not been attributed to a named group, campaign, or government. Their objectives beyond obtaining data and credentials remain unknown.

Credential Rotation Must Extend Beyond Cadence

JetBrains has taken api.cadence.jetbrains.com offline and invalidated all access tokens used by the Cadence plugin in PyCharm. Those measures block the existing connection path, but they do not invalidate credentials copied from projects, backups, or execution environments.

Affected users and organizations should:

1. Revoke and rotate every password, token, API key, SSH key, certificate, and secret stored in Cadence or exposed to a Cadence execution.
2. Replace credentials associated with AWS IAM users and other cloud identities used by the service.
3. Identify downstream systems accessible with those credentials, including repositories, registries, deployment environments, cloud accounts, databases, and package platforms.
4. Audit repositories for unauthorized access, commits, downloads, webhook changes, new collaborators, modified permissions, and newly issued tokens.
5. Review cloud audit logs for IAM changes, new accounts, unusual role assumptions, policy modifications, and unexpected S3 access.
6. Inspect build, package, container, and release systems for unauthorized publication or modification.
7. Validate Cadence-generated outputs before reusing or distributing them.
8. Search connected systems for persistence, new service accounts, altered trust relationships, and reused credentials.

Rotation should include dependent access. Replacing an AWS key, for example, is insufficient if the same secret was reused in a repository, CI/CD platform, local configuration file, or another cloud environment.

Exposed names and email addresses also create a secondary risk. Attackers could use knowledge of Cadence projects or JetBrains workflows to craft targeted phishing messages, impersonate administrators, or solicit replacement credentials from affected developers.

The immediate TeamCity entry point has been removed from service. The harder task is determining where the extracted identities could reach—and whether the attackers used them before they were revoked.