JetBrains Cadence breached through an unpatched TeamCity flaw, AWS IAM credentials exfiltrated
Attackers exploited CVE-2026-63077 (CVSS 9.8) to break into Cadence, JetBrains’ cloud GPU service, between August 8 and 24, 2026, exfiltrating AWS IAM credentials and data held in S3 buckets. Revoke and rotate every credential and secret tied to Cadence without delay.
September 5, 2026. JetBrains reveals that attackers broke into Cadence, its cloud GPU computing service, by exploiting a critical flaw in TeamCity — the product JetBrains itself builds. The intrusion, which ran from August 8 to August 24, 2026, let the attackers exfiltrate AWS IAM credentials and data stored in S3 buckets. Why it matters: a developer-tools vendor failed to patch its own instance of its own CI server, and its customers’ cloud secrets paid the price.
Cadence, a cloud GPU wired into the IDE
Cadence is a JetBrains-hosted service that integrates with PyCharm through an optional plugin. Its promise: run heavy workloads — machine learning, model training, intensive compute — on cloud GPUs straight from the IDE, without managing the infrastructure yourself.
That promise has an invisible corollary. For executions to work, Cadence has to hold cloud credentials: AWS IAM keys, secrets, access tokens, and paths into S3 buckets. That is exactly what an attacker goes looking for when they target a service like this. A compromise here doesn’t hit static files — it hits the secret store of a whole population of developers.
CVE-2026-63077, the TeamCity flaw JetBrains didn’t fix at home
The entry point is CVE-2026-63077, an untrusted data deserialization bug in TeamCity rated CVSS 9.8. It lets an unauthenticated attacker with network access to the server bypass authentication and run arbitrary OS commands with the privileges of the TeamCity process. In other words, remote code execution with no prior credentials at all.
The flaw has been known for weeks. CISA added it to the KEV (Known Exploited Vulnerabilities) catalog on August 5, 2026, a signal that it was already being exploited in the wild. JetBrains patched the product — but, by its own admission, the compromised Cadence server had not received the fix. The company concedes the instance “should have been patched as part of its own vulnerability response efforts,” without explaining why it wasn’t.
The irony is heavy. TeamCity is a continuous integration server sold to orchestrate pipelines and handle deployment secrets. The vendor that sells it didn’t apply its own patch to its own production infrastructure. It’s the modern, cloud-era version of the shoemaker’s children going barefoot.
What the attacker got
JetBrains discovered the intrusion on August 23, 2026. The attacker was active from August 8 to August 24. The list of data confirmed as accessed or compromised is long:
- Personal data: 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 the associated credentials/secrets used with Cadence, including IAM identities belonging to JetBrains employees.
- Files stored in S3 buckets within the AWS accounts JetBrains used for the service.
- Potentially source code synchronized from PyCharm to the compromised server, covering scenarios where developers uploaded project files for execution.
The exploited server, api.cadence.jetbrains.com, has been taken offline. JetBrains has also invalidated every access token used by the Cadence plugin in PyCharm.
Indicators of compromise worth treating as an alert
JetBrains published a list of indicators. Malicious activity is observable starting August 8, 2026, particularly authentications or actions carried out with credentials previously stored in — or reachable through — Cadence. The IP addresses associated with the observed exploitation are:
150.109.230.104
43.153.227.206
62.210.127.48
210.247.242.190
15.235.225.205
152.233.30.18Beyond those IPs, JetBrains asks teams to watch for any abnormal activity: logins from unexpected addresses, unsolicited repository clones or commits, changes to repository secrets or webhooks, new access tokens, new service accounts, IAM role or policy changes in the cloud, unusual access to S3 storage, and unexpected package publications or modifications.
CI/CD servers, the new gateway into the cloud
TeamCity is not an isolated target. CI servers — TeamCity, Jenkins, GitLab CI — have become the preferred on-ramp for attackers heading for the cloud, for one simple reason: they concentrate deployment secrets. An IAM key living inside a pipeline is worth more than a password, because it opens the AWS account that runs production.
Recent history backs this up. TeamCity was already mass-exploited in early 2024 through CVE-2024-27198 and CVE-2024-27199, two authentication and code-execution flaws that let ransomware groups walk into whole networks. Code-analysis vendor Codecov was compromised in 2021, CircleCI in January 2023 — each time, the prize was the same: cloud credentials hosted inside a developer tool, then resold or abused. CVE-2026-63077 belongs to the same line, with one twist: this time the victim is the vendor of the product itself.
The lesson is structural. Long-lived static AWS IAM keys are the worst possible choice inside a CI pipeline: once exfiltrated, they stay valid until someone manually revokes them, however long detection takes. OIDC and short-lived tokens, which expire before they can be used, are the technical answer to this class of incident — the one JetBrains has just illustrated against itself.
What to do
JetBrains’ instruction is unambiguous: revoke or rotate immediately every credential and secret that may have been used for Cadence executions, and treat all executions as potentially untrusted. In practice:
- Rotate the exposed AWS IAM keys and audit the S3 buckets, deployment environments, and registries reachable with those credentials.
- Audit source code repositories for any unauthorized changes during the August 8–24 window.
- Watch service accounts and IAM policy changes across AWS and Google Cloud.
# List a user's access keys
aws iam list-access-keys --user-name my-user
# Deactivate a potentially compromised key
aws iam update-access-key --user-name my-user --access-key-id AKIA... --status InactiveThese steps do more than protect against this incident: they shrink the surface of the entire class of third-party hosted-secret compromises. The most likely consequence, per JetBrains, is a rise in targeted phishing and social engineering using the exposed names and email addresses — a reminder that the cost of leaked credentials is often paid as the setup for a second attack.
A two-week dwell time is a red flag
The August 8–24 window deserves its own attention. A breach discovered on August 23 that had been active since August 8 means the attacker had roughly two weeks of quiet access before JetBrains cut it off. In credential-theft incidents, that dwell time is rarely idle: stolen IAM keys and S3 access are often stockpiled and resold, or used later once the initial panic has passed.
For a Cadence user, the practical consequence is that a key you rotate today may already have been tested against your AWS account weeks ago. Rotation is still correct — but it must be paired with a CloudTrail review across the intrusion window, not just a credential swap. A key that was exfiltrated and never yet used is a live weapon; rotation is the disarmament, and the audit is how you confirm it wasn’t already fired.
Verdict
If you’ve used Cadence, revoke and rotate all tied credentials, starting with your AWS IAM keys: the attacker explicitly exfiltrated this class of secrets, and a two-week intrusion window leaves room for delayed use.
If you run a cloud service that holds your secrets, take the lesson of this incident to heart: the patch has existed since August 5, but it wasn’t applied to the instance that mattered. Prefer short-lived tokens and OIDC over long-lived static keys, so an exfiltrated secret expires before it can be used.