The breach of JetBrains Cadence is a particularly important incident because it combines several high-risk elements in one attack: an internet-facing CI/CD component, a critical unauthenticated remote-code-execution vulnerability, cloud credentials, source code, backups and developer infrastructure. JetBrains confirmed that attackers exploited CVE-2026-63077 in a TeamCity server used to orchestrate Cadence workloads, gaining unauthorized access to `api.cadence.jetbrains.com` between August 8 and August 24, 2026. The vulnerability carries a CVSS score of 9.8 and involves deserialization of untrusted data, allowing an unauthenticated attacker with network access to a vulnerable TeamCity server to bypass authentication checks and execute arbitrary operating-system commands with the privileges of the TeamCity process. Once that boundary was crossed, the attackers were no longer merely inside a build server. They had access to an environment that was designed to handle source code, credentials, cloud resources and automated execution on behalf of developers. 

The most striking detail is that JetBrains had already disclosed CVE-2026-63077 on July 27 and had warned of active exploitation against unpatched TeamCity servers. Yet JetBrains later acknowledged that the Cadence server itself “should have been patched” as part of the response and was not. That admission is significant because it illustrates one of the most persistent failures in vulnerability management: knowing that a critical vulnerability exists is not the same as proving that every affected asset has actually been remediated. Patch advisories, internal tickets and remediation plans are useful only if asset inventory, ownership and verification processes ensure that no exposed system is missed. In this case, the forgotten system was not an obscure test box. It was part of a production developer service connected to sensitive resources.

The attackers gained access to a full Cadence server backup dating from 2024. That backup contained credentials, configuration, artifacts, logs and other information that JetBrains now considers potentially exposed. This is an important reminder that backups frequently preserve far more than application data. They can contain long-lived secrets, API tokens, historical configuration, service-account credentials, cloud keys and debugging information that no longer exists in the live environment. A backup therefore becomes a time capsule of trust relationships. If an attacker steals it, they may gain access to credentials that administrators forgot existed or assumed had become irrelevant years earlier. JetBrains confirmed that multiple AWS IAM users and associated secrets were compromised through information present in the backup, including credentials belonging to JetBrains employees.

The incident also demonstrates why credential rotation needs to follow exposure, not merely confirmed use. JetBrains is advising Cadence users to revoke or rotate every credential or secret that may have been used during Cadence executions, including cloud credentials for AWS, Azure and Google Cloud, source-control tokens for GitHub, GitLab and Bitbucket, package-repository credentials for npm, Maven, NuGet and PyPI, container-registry credentials, Slack tokens, webhooks, API tokens, SSH keys, signing certificates and other external-system secrets. This guidance is broad because once attackers gain access to the execution environment, there is no reliable way to prove that every individual secret remained untouched. The correct security assumption is therefore that accessible credentials are compromised until rotated.

That distinction is especially important in developer infrastructure. Build and execution systems routinely need access to cloud accounts, package repositories, deployment environments and source-code platforms. The credentials are present precisely because automation requires them. From an attacker’s perspective, compromising such a system can therefore be far more valuable than compromising an ordinary workstation. One successful intrusion can produce a collection of credentials capable of opening multiple downstream environments, effectively turning the CI/CD platform into a credential aggregation point.

JetBrains also confirmed that attackers accessed files in S3 buckets belonging to JetBrains AWS accounts used by Cadence and may have accessed source code synchronized from PyCharm projects to the affected server. As of its final update on September 3, JetBrains said storage associated with current Cadence users may also have been reachable, including email addresses, project source code and credentials. The company is therefore treating that data as potentially exposed, even though it did not identify additional affected users.

The source-code exposure creates a second layer of risk. Attackers with access to private repositories or synchronized project files can search for embedded secrets, internal API endpoints, hardcoded credentials, unpublished vulnerabilities or information about infrastructure architecture. Even if no malicious modifications are made during the original intrusion, the stolen source code can enable better-targeted attacks later. Security teams therefore need to consider source-code theft not simply as an intellectual-property issue but as reconnaissance that may increase the effectiveness of future attacks.

The potential supply-chain implications are even more serious. JetBrains explicitly recommends reviewing repositories for unexpected clones, downloads and commits, as well as changes to secrets, webhooks, collaborators and permissions. Organizations should also inspect package and container registries for unauthorized publication or modification. This guidance reflects the privileged position of Cadence and TeamCity within the development lifecycle. If attackers obtain sufficient access, they may be able to tamper with software before it reaches production or alter artifacts consumed by downstream systems.

This is precisely why CI/CD systems deserve to be treated as Tier-0 or near-Tier-0 infrastructure in many organizations. A compromised build system can potentially affect hundreds of applications and environments without attackers having to compromise each target individually. Build platforms should therefore receive stronger security controls than conventional internal applications, including aggressive patching, limited network exposure, multi-factor authentication, strong secrets isolation and extensive logging.

The Cadence breach also highlights the danger of long-lived cloud credentials. AWS IAM keys stored in a 2024 backup were still sufficiently valuable to warrant compromise response in 2026. This is one of the clearest arguments for replacing static access keys with short-lived identity federation wherever possible. Technologies such as OIDC-based workload identity allow build systems to obtain temporary credentials at runtime rather than storing reusable secrets indefinitely. JetBrains itself has been promoting OIDC-based authentication for TeamCity builds, and incidents like this demonstrate exactly why that architecture is preferable.

Short-lived credentials do not eliminate compromise, but they reduce the usefulness of historical backups. A two-year-old backup containing expired tokens is far less dangerous than one containing static cloud keys that remain valid. Security architecture should therefore aim to make yesterday’s secrets useless today.

Another notable aspect is the affected period. Attackers began activity on August 8, JetBrains detected exploitation on August 23 and took the server offline on August 24. That roughly two-week dwell period matters because CI/CD infrastructure can generate enormous volumes of legitimate activity, making malicious operations difficult to distinguish from normal automation. A build server cloning repositories, accessing S3 buckets or publishing artifacts may be completely normal. The defensive challenge is therefore detecting when those actions occur in an unusual context, from unexpected IP addresses or with abnormal frequency.

JetBrains has published several indicators associated with the incident, including source IP addresses and behavioural signs such as unexpected repository activity, new or modified tokens, new service accounts, unexpected IAM changes and unusual access to cloud storage. These are useful for immediate hunting, but the company also stresses that the indicators are not exhaustive and that absence of a match does not prove that a customer was unaffected. That is the correct position. Once attackers gain control over infrastructure and credentials, they can change IP addresses and tools rapidly. Detection must therefore focus on behaviour and access patterns rather than only static indicators.

Organizations that used Cadence during the affected period should review activity from August 8 onward, particularly authentication using credentials that were available to Cadence. They should inspect AWS CloudTrail, Azure and Google Cloud audit logs, source-control audit logs, package registries and deployment environments for unusual operations. Repository clones from unfamiliar locations, new SSH keys, unexpected API tokens and altered IAM roles all deserve investigation. JetBrains also advises treating every Cadence execution, including its inputs and outputs, as potentially untrusted.

This recommendation is important because attack impact may propagate through artifacts generated by the compromised system. If an attacker could influence a build or execution, the output itself may be malicious even if the surrounding infrastructure has since been secured. Organizations should therefore validate artifacts produced during the affected period rather than assuming that a successful pipeline execution means the result is trustworthy.

The breach also provides an important lesson about backups and retention. Organizations often preserve full server backups because they are operationally convenient, but security teams should ask whether every secret needs to survive inside those images. Before backups are retained long term, sensitive credentials should ideally be externalized into secrets-management systems rather than embedded in configuration files or disk images. Backup encryption is necessary, but it does not fully solve the problem if an attacker compromises the system or account authorized to decrypt it.

Network architecture matters as well. TeamCity and similar orchestration servers should not be unnecessarily reachable from the public internet. If remote access is required, exposure should be tightly controlled through VPNs, zero-trust access layers or restrictive allowlists where operationally feasible. A critical unauthenticated RCE becomes dramatically easier to exploit when the vulnerable service is available to anyone capable of opening a TCP connection from the internet.

The incident also reinforces the importance of independent patch verification. Organizations should not consider a critical vulnerability closed because a change request says “patched.” Security teams should automatically query software versions after remediation, compare them against known vulnerable releases and continuously scan for stragglers. For critical infrastructure, remediation completion should be measurable rather than administrative.

There is an uncomfortable irony in JetBrains falling victim to a vulnerability in its own product after advising customers to patch. But the more useful lesson is not to mock the vendor. The incident demonstrates how difficult vulnerability management becomes when organizations operate large numbers of services, backups, internal systems and cloud workloads. Even security-aware companies can miss one critical asset. The defensive response should therefore be to design systems that assume humans will occasionally miss something.

That means maintaining authoritative asset inventories, automatically identifying vulnerable versions, enforcing patch deadlines, reducing internet exposure and verifying remediation continuously.

The deeper lesson from the Cadence breach is that developer infrastructure is now one of the highest-value targets in the enterprise.

A compromised CI/CD server can expose far more than the server itself.

It can expose source code, cloud identities, deployment credentials, package repositories, signing infrastructure and the trust relationships that connect them all.

Attackers do not have to compromise every application individually if they can compromise the machinery that builds and deploys them.

That is what makes incidents like this particularly dangerous: the attack begins in one server, but the trust it inherits can reach almost everywhere.

JetBrains is urging Cadence users to revoke and rotate all credentials following a security incident last month in which unidentified threat actors exploited a recently disclosed critical vulnerability in TeamCity to breach its own environment. "Cadence users should immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions," JetBrains said.

Source: Attackers Breached JetBrains Cadence via Unpatched TeamCity, Extracting AWS Credentials via The Hacker News — published 05 Sep 2026.