JetBrains confirms that attackers broke into its Cadence cloud service by exploiting a critical TeamCity vulnerability the company had already patched — just not on that particular server.

JetBrains is telling users of Cadence, its cloud execution service for PyCharm, to rotate every credential and secret they've ever used with it. The reason is blunt: the server behind Cadence should have been patched against a critical remote-code-execution bug back in July. It wasn't, and someone found that out before JetBrains did.

What happened

Cadence is a JetBrains-hosted service that plugs into PyCharm and lets developers run machine-learning and other heavy workloads on cloud GPUs without leaving the IDE. [1] Under the hood, it uses JetBrains TeamCity to orchestrate those jobs. [2] That dependency is what turned a CI/CD vulnerability into a data breach.

According to JetBrains, threat actors gained unauthorized access to the Cadence server api.cadence.jetbrains.com starting August 8, 2026. The company discovered the exploitation on August 23 and pulled the server offline the next day. [2] That's a two-week window in which attackers apparently had a foothold before anyone noticed.

The vulnerability: CVE-2026-63077

The root cause traces back to a TeamCity flaw JetBrains disclosed on July 27, 2026, and assigned CVE-2026-63077. It's a deserialization-of-untrusted-data bug that lets an unauthenticated attacker with network access to a TeamCity server bypass authentication entirely and run arbitrary operating system commands, with whatever privileges the TeamCity server process has. [3] No login required. No user interaction needed. Just HTTP(S) reachability.

Security researcher Stephen Fewer at Rapid7 later dug into the mechanics: a patched TeamCity server is supposed to lock down which Java classes can be deserialized during agent requests using an XStream allowlist, but the vulnerable configuration added TeamCity's own protocol classes to that list without first stripping XStream's dangerous defaults. The fix inserts a "deny everything, then allow specific things" rule before the TeamCity allowlist — effectively closing a door that had been left wide open. [4] Rapid7 published a proof-of-concept so organizations could test their own exposure; the flaw was already being exploited in the wild by the time that PoC came out.

All on-premises TeamCity versions were affected. TeamCity Cloud was not — JetBrains says it had already applied the necessary protections there and found no evidence of exploitation against cloud environments. [3]

JetBrains fixed the bug in versions 2025.11.7 and 2026.1.3, and released a standalone security patch plugin for anyone running older, still-supported builds who couldn't upgrade immediately. [3]

From disclosure to active exploitation

Patching a flaw doesn't make it disappear from the internet's memory. Within about ten days of JetBrains' initial advisory, CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog on August 5, 2026, and gave U.S. federal civilian agencies until August 8 to patch or mitigate under Binding Operational Directive 26-04. [5] That's an unusually tight three-day runway, which tells you how seriously the agency treated it.

Here's the part that stings: the Cadence server was exploited using this exact vulnerability, on a server that, by JetBrains' own account, "should have been patched as part of our response to the vulnerability, but it was not." [2] The company didn't offer a reason why it fell through the cracks — just an apology. It's a reminder that having a documented patch process and actually executing it against every server in your fleet are two different things, and the gap between them is exactly where incidents like this live.

What the attackers actually got

JetBrains' investigation, updated as recently as September 3, 2026, lays out what was confirmed compromised [2]:

• Personal data on Cadence users — usernames, real names, email addresses, last-login timestamps, and last-accessed IP addresses
• A full backup of the Cadence server dating from 2024, containing credentials, configuration, artifacts, and logs
• Multiple AWS IAM users and their associated credentials, extracted from that 2024 backup — including accounts belonging to JetBrains' own employees
• Files stored in S3 buckets inside JetBrains' AWS accounts tied to Cadence

JetBrains also flagged, as a possibility rather than a confirmed fact, that source code synchronized from PyCharm projects into Cadence for execution could have been exposed, along with any credentials embedded in that code. [2]

Notably, the company says this second wave of findings — the current-environment storage exposure disclosed September 3 — affects the same group of users it had already contacted directly, not a new set of victims. [2] That's a meaningful distinction if you're trying to figure out whether you personally need to act.

Who needs to do something right now

If you've ever used the Cadence plugin in PyCharm, JetBrains wants you to treat every credential that touched that service as burned. Specifically:

• Revoke and rotate all credentials and secrets used in Cadence executions — cloud (AWS, Azure, GCP), source control (GitHub, GitLab, Bitbucket), package registries (npm, PyPI, NuGet, Maven), container registries, Slack tokens, SSH keys, signing certificates, all of it
• Review AWS accounts, S3 buckets, and any connected deployment environments for suspicious activity
• Audit source repositories for unauthorized commits during the affected window
• Treat every past Cadence execution's inputs and outputs as untrusted

JetBrains has published indicators of compromise, including six specific IP addresses tied to the observed exploitation activity and a list of behavioral red flags — unexpected IAM policy changes, new personal access tokens, unfamiliar service accounts, and unexpected access to cloud storage. [2] Security teams should treat August 8, 2026 onward as the relevant lookback window for any credential that ever passed through Cadence.

The bigger pattern here

This isn't really a story about one bad deserialization bug. TeamCity has been a repeat target precisely because it sits at a privileged point in the software supply chain — compromise the build server and you potentially compromise everything it touches downstream. What makes the Cadence incident notable is that it shows the failure mode that matters most in practice: not zero-days, but patches that exist and simply don't get applied everywhere they need to be, fast enough. A three-day CISA remediation deadline is a strong signal, and it still wasn't enough to catch every exposed instance.

For teams running TeamCity on-premises anywhere in their pipeline — not just the flagship instance everyone remembers to patch — this is a good moment to confirm every instance, including staging, internal tooling, and anything wired into a vendor's own infrastructure, is actually on 2025.11.7, 2026.1.3, or has the security patch plugin applied.

Security takeaway

CVE-2026-63077 was disclosed responsibly, patched promptly, and still caused a breach — because one server didn't get the memo. If there's a lesson for defenders beyond "patch TeamCity," it's that CISA KEV listings and vendor advisories are only as good as the asset inventory that turns them into action. Know every internet-facing TeamCity server you run, not just the ones you remember.

Sources & References

1. JetBrains — "Training your ML models with Cadence"
2. JetBrains — "Security Incident Affecting JetBrains Cadence" (updated Sept 3, 2026)
3. JetBrains — "Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)" (July 27, 2026, updated Aug 7)
4. The Hacker News — "CISA Flags TeamCity CVE-2026-63077 RCE Flaw Under Active Exploitation in the Wild" (Aug 6, 2026), citing Rapid7/Stephen Fewer and CISA KEV
5. The Hacker News — "Attackers Breached JetBrains Cadence via Unpatched TeamCity, Extracting AWS Credentials" (Sept 5, 2026)