Breach · Vendor Access

JetBrains Breached Its Own Cadence Environment by Skipping a Patch It Told Everyone Else to Apply

September 7, 2026 · 5 min read

On July 27, 2026, JetBrains published a security advisory for CVE-2026-63077, a CVSS 9.8 unauthenticated remote code execution flaw in TeamCity On-Premises, and told the world to patch immediately. CISA added it to the Known Exploited Vulnerabilities catalog on August 5. By August 8, attackers had found a TeamCity instance that JetBrains itself had failed to patch, and they spent the next sixteen days inside the company's own Cadence cloud-compute environment. The irony is hard to miss, but the operational lesson underneath it is worth spending time on.

What actually happened

CVE-2026-63077 is a deserialization vulnerability (CWE-502) that affects all TeamCity On-Premises versions prior to 2025.11.7 or 2026.1.3. Rapid7's analysis confirmed that exploitation is achievable over standard HTTP or HTTPS via the TeamCity agent polling protocol, taking advantage of a permissive XStream allowlist that a vulnerable server maintains. There is no authentication required. An attacker who can reach the server's network port can execute arbitrary code on the host. JetBrains had already applied the fix to its TeamCity Cloud infrastructure before publishing the advisory, which made the failure to patch the Cadence API server (api.cadence.jetbrains.com) all the more difficult to explain.

The breach window ran from August 8 to August 23, 2026, when JetBrains detected the malicious activity. The company took the Cadence server offline on August 24. During that sixteen-day window, threat actors accessed a full server backup from 2024. That backup contained usernames, real names, email addresses, last-login timestamps, last-accessed IP addresses, and AWS IAM credentials. JetBrains has not disclosed the total number of affected users.

JetBrains acknowledged in its official incident statement that the Cadence API server should have been patched as part of its own vulnerability-response process.

The company is now urging every Cadence user to immediately revoke and rotate credentials across every platform that may have touched a Cadence execution: AWS, Azure, GCP, GitHub, GitLab, Bitbucket, npm, PyPI, Docker registries, Slack, SSH keys, and signing certificates. Any Cadence execution or output produced between August 8 and August 24 should be treated as untrusted until credentials are rotated and access logs are reviewed.

Why this should matter to you even if you don’t run JetBrains Cadence

If you run TeamCity On-Premises and have not yet applied the patch to version 2025.11.7 or 2026.1.3, that is the first thing to do today. CISA set a federal agency deadline of August 8, 2026 under BOD 26-04. That date has passed. Active exploitation was confirmed before JetBrains' own infrastructure was hit, so the risk is real and documented.

The broader concern here goes past TeamCity. JetBrains is a sophisticated software vendor that publishes security advisories, runs a coordinated disclosure process, and employs people who understand what CVE-2026-63077 means. They still shipped a patch to their cloud product and left an internally managed server running a vulnerable version for weeks. This happens everywhere. Organizations routinely have better patch coverage on their customer-facing perimeter than on internal tooling, build infrastructure, and compute environments that are treated as semi-trusted or assumed to be behind enough layers that external exposure seems unlikely.

The Cadence environment is a useful example because CI/CD and cloud-compute orchestration platforms are credential-dense by design. They need to authenticate to source control, artifact registries, cloud provider APIs, deployment targets, and notification systems. A 2024 backup containing AWS IAM credentials is a concrete illustration of what attackers find when they get into that kind of infrastructure. Credential exfiltration from a build environment can give an attacker a map of your entire cloud footprint, without them ever touching production directly.

For organizations that use JetBrains Cadence: the affected execution window is August 8 through August 24, 2026. Treat that window as compromised and rotate accordingly. For organizations that depend on any third-party CI/CD or cloud-compute vendor: this incident is a reminder that your vendor's internal patch hygiene is part of your risk surface, whether you can see it or not.

The control that would have blunted it

The control that would have materially reduced the impact here is credential isolation combined with just-in-time access provisioning for CI/CD workloads. The root cause of the worst downstream exposure in this incident was that long-lived AWS IAM credentials were present in a server backup. Long-lived credentials stored in compute environments accumulate over time, and backups preserve them indefinitely. If the Cadence environment had been provisioned with short-lived credentials generated at execution time via IAM roles or similar identity federation mechanisms, the credentials recovered from a 2024 backup would have been expired and useless.

This is worth being specific about. AWS supports role assumption via IAM roles for EC2 instances and ECS tasks, and many CI/CD platforms support OIDC-based federation that allows workloads to request short-lived tokens scoped to the specific job being run. When those tokens expire (typically in minutes to hours), they are worthless to an attacker who retrieves them later. The tradeoff is real: configuring OIDC federation or role-based access for every integration is more work up front, requires careful scoping of permissions per workflow, and introduces a dependency on the identity provider being available at execution time. It also makes debugging harder when tokens expire mid-run. These are solvable problems, but they require deliberate engineering time.

The patch failure itself points to a process control: vendor patch SLA verification. Cyber insurers increasingly ask whether organizations have documented patch SLAs for critical vulnerabilities and whether those SLAs are audited. Most organizations apply that requirement inward, to their own systems. The JetBrains incident is an argument for extending that scrutiny outward to vendors who run infrastructure on your behalf. That means asking vendors, in writing, whether critical CVEs affecting their own infrastructure have been remediated, and within what timeframe. A vendor that publishes an advisory for a CVSS 9.8 flaw and fails to apply it internally within the same window they recommend to customers is a vendor whose patch process deserves a closer look.

Both controls are partial answers. Credential rotation after the fact (which JetBrains is now requiring) is a recovery action. Short-lived credentials reduce the blast radius of a backup exfiltration, and the initial intrusion still required a patched server. All three layers matter, and the failure in this case was at the most basic one: applying an available patch to a known-vulnerable system within a defined window.

Strondex's Vendor Risk product helps you track patch compliance commitments from third-party infrastructure providers and flag gaps before they become incidents.