The JetBrains Cadence breach and why it matters
Cadence is a JetBrains-hosted cloud computing service that runs machine learning and heavy workloads on cloud GPUs through a PyCharm plugin. Last month, attackers exploited CVE-2026-63077 in an unpatched TeamCity server to break into JetBrains’ own Cadence environment and pull AWS credentials. That sentence is the whole story in one line, and it is the part that should keep a few people up at night. The vendor that sells developer tools to the rest of us got popped through a known, critical, already-in-the-wild bug in its own build server. According to The Hacker News (opens in new tab), JetBrains conceded the affected server should have been patched as part of its own vulnerability response work. The company has not explained why that did not happen. If a software vendor of JetBrains’ size can leave a CVSS 9.8 hole open on a production build server, the rest of us have to take the lesson seriously, because the same basic failure mode shows up at smaller shops all the time: a known patch, a known exposure window, and a busy team that never quite gets to it.
How the JetBrains Cadence breach started with an unpatched TeamCity server
CVE-2026-63077 is a deserialization flaw with a CVSS score of 9.8. In plain English, an unauthenticated attacker who can reach the TeamCity web interface can bypass the login screen and run operating system commands as the TeamCity server user. No password, no MFA prompt, no nothing. That is the kind of bug where the fix has to go out the same day the advisory lands, because exploitation tooling tends to follow within hours, not weeks.
The timeline here is the part that should make any sysadmin wince. CISA added the flaw to the Known Exploited Vulnerabilities catalog on August 5, 2026. JetBrains says the actual intrusion ran from August 8 to August 24, 2026, and was only discovered on August 23. So the bug went from “on KEV” to “actively abused in our environment” in three days, and the abuse went undetected for roughly two weeks. Eighteen days of attacker access to a server that held a 2024 Cadence backup, which in turn held AWS IAM users and secrets, configuration files, and execution logs. JetBrains’ public position is that the server should have been patched. They have not said why it was not, and I do not want to speculate beyond the facts, but the gap between CISA listing a CVE and a vendor patching it is the exact window threat actors hunt for.
What JetBrains is telling Cadence users right now
The data the attackers are confirmed to have accessed includes personal data (usernames, real names, email addresses, last-login timestamps, last accessed IP addresses), a full 2024 Cadence server backup containing credentials and configuration, multiple AWS IAM users and associated secrets, files in JetBrains-owned S3 buckets, and source code synced from PyCharm projects. JetBrains has invalidated every access token used by the PyCharm Cadence plugin, and the api.cadence.jetbrains.com server has been taken offline.
JetBrains is telling users, in writing, to revoke or rotate all credentials and secrets that may have run a Cadence execution, and to treat every execution, including its inputs and outputs, as potentially untrusted. That second part matters more than people realize. If you uploaded a project that contained an .aws/credentials file, a Terraform state file with an embedded access key, or even a hardcoded API token in a config, an attacker who read the execution inputs now has those too.
Questions you should be asking right now
If you used Cadence in the last month, assume your AWS credentials are compromised, full stop. JetBrains confirmed that AWS IAM users and secrets were extracted from the 2024 backup, and that includes IAM users belonging to JetBrains employees who used the service. Even if you only used Cadence once for a quick experiment, rotate. The cost of rotating an unused key is five minutes; the cost of not rotating a key that someone decides to burn is measured in your AWS bill and your incident response time.
What counts as a compromised credential? Three buckets, and they overlap. Anything stored in Cadence, anything inside the 2024 server backup, and anything you ever passed to an execution running on api.cadence.jetbrains.com. If you synced code from PyCharm, anything embedded in that code is also in scope. Think of it like a plumber showing up to fix a leaking pipe: they have to assume every tool they touched and every joint they looked at might be contaminated, because you cannot prove the water only reached the one place you saw. Same logic here. You cannot prove the attacker only read the one file they exfiltrated.
Indicators of compromise and the aftermath
JetBrains published a set of IoCs, and these are the ones worth grepping your logs for tonight. Authentication or activity from these IPs: 150.109.230.104, 43.153.227.206, 62.210.127.48, 210.247.242.190, 15.235.225.205, and 152.233.30.18. Authentication from unexpected IP addresses or locations you do not recognize. Unexpected repository clones or downloads. Changes to repository secrets, webhooks, collaborators, or permissions. New personal access tokens or API tokens you did not create. New service accounts in connected systems. Unexpected IAM role or policy changes. Unexpected reads or writes against S3 buckets. Unexpected package or release publishes from your accounts.
The attacker has not been identified, and nothing in the public reporting suggests a particular threat actor. My expectation is that the stolen AWS credentials will be sold or held rather than burned immediately on a loud crypto-mining spike, which is the more common pattern for this kind of access, but that is a guess, not a fact, and you should plan for the worst. Assume the keys are live and in someone else’s hands right now.
Rotate credentials now, not after you see the bill
Here is what to do today, in order. First, revoke and rotate every AWS IAM user and secret that touched Cadence, including any keys that belonged to employees who ran executions, then move on to anything in the 2024 backup, then to anything passed to an execution. Second, audit your own TeamCity instances against the CVE-2026-63077 patch and apply it tonight if you are behind, because the same exploit chain works on any unpatched TeamCity box, not just JetBrains’. Third, search your web server, WAF, and TeamCity logs for the six published IPs and for any auth event from a country your team does not live in. Fourth, check your S3 access logs for unexpected GETs between August 8 and August 24. Fifth, treat your PyCharm-synced code as exposed and rotate anything embedded in it.
The uncomfortable takeaway is that a hosting provider’s internal patch discipline matters as much as your own. You can do everything right on your side, and if the vendor leaves a 9.8 deserialization bug open on a build server that holds a backup of your credentials, your keys still walk out the door. Audit your own TeamCity today and rotate anything that ever touched Cadence before the attackers use it for you.