A single unpatched build server just showed the rest of the industry what happens when a known CI/CD vulnerability sits unfixed for weeks. JetBrains has confirmed that its Cadence cloud service, which runs customer workloads from PyCharm, was breached through a TeamCity flaw the company itself had already patched for its own customers. Cadence’s own server was not one of them. The result: source code, cloud credentials, and a full 2024 server backup all in an attacker’s hands, and a security industry once again relearning that patch management is the control that keeps failing everyone, including the vendors who sell patch management.
What happened
JetBrains says attackers exploited CVE-2026-63077, a critical deserialization flaw in TeamCity that lets an unauthenticated attacker run arbitrary commands on a vulnerable server. The company had already shipped a fix and issued guidance to TeamCity customers. Its own Cadence server, which uses TeamCity internally to orchestrate customer workloads, was never updated to that fix. Attackers found the gap and used it.
According to JetBrains, the intrusion window ran from August 8 to August 24, 2026. The company discovered the exploitation on August 23 and took the affected server, api.cadence.jetbrains.com, offline the following day. “We sincerely apologize for this failure and the impact it may have on you,” Daniel Gallo wrote in the incident update on the JetBrains blog.
Media Partner
What was taken
JetBrains says confirmed data includes usernames, real names, email addresses, last-login timestamps, and IP addresses tied to Cadence accounts. Far more consequential for downstream security teams: the attackers also compromised a full backup of the Cadence server dating from 2024, which JetBrains says means any credentials, configuration, or logs present in that backup have to be treated as exposed too.
That backup reportedly included multiple AWS IAM users and their associated credentials and secrets, some belonging to JetBrains employees who used the service, plus access to files stored in S3 buckets inside JetBrains’ own AWS accounts. JetBrains says it does not yet know whether attackers reached storage buckets inside customer accounts, but warns that any customer who configured Cadence to reach their own buckets should treat those connection credentials as compromised as well. Source code synchronized from PyCharm projects into Cadence for execution is in the same category.
JetBrains is telling every affected user to revoke or rotate credentials across a list that reads like a company’s entire toolchain: cloud accounts on AWS, Azure, and Google Cloud; source control tokens for GitHub, GitLab, and Bitbucket; package registry credentials for npm, Maven, NuGet, and PyPI; container registry and SSH deployment keys; and any other service token an execution on the compromised server might have touched.
Why a build-server flaw keeps doing this
This is not a novel failure mode. CI/CD systems sit at the center of a company’s software supply chain by design: they hold the credentials needed to pull code, push builds, and deploy to production, which is exactly why compromising one server can cascade into every connected cloud account, registry, and repository at once. What makes this incident notable is not the mechanism but the source. JetBrains builds TeamCity, sells it as the tool other companies use to secure their own pipelines, and still ran an unpatched instance of it in production for at least two weeks after a fix existed. GitGuardian’s recent research into credential-hunting supply chain worms, covered in The Supply Chain Worm Now Hunts AI Agent Credentials, made the same point from the attacker side: automated tooling now actively searches compromised environments for exactly the kind of cloud and registry secrets that sat in Cadence’s 2024 backup.
The pattern also echoes a separate lesson from this year: a single vendor’s compromise reaching far past its own customer list. Court systems across a dozen states learned that when a shared software vendor was breached, covered in A Single Vendor Breach Just Hit a Dozen State Courts. Cadence is the same shape of risk in a different sector: a shared cloud service sitting between many customers and their own infrastructure, one unpatched dependency away from exposing all of them at once.
What it means for the security leader
If your organization used Cadence to run PyCharm projects on JetBrains’ cloud compute, the rotation list JetBrains published is not optional homework. Every credential category on it should already be moving through your incident response process: cloud IAM keys, source control tokens, package registry credentials, and SSH or deployment keys. Treat the 2024 backup exposure as the baseline assumption, not a worst case, since JetBrains itself says the backup’s full contents cannot yet be ruled out.
For everyone else, the more durable lesson is about internal patch SLAs for build infrastructure specifically. A CVSS 9.8 deserialization bug in a CI/CD orchestrator is exactly the class of flaw that needs an emergency patch window, not a routine one, because the blast radius runs through every credential the pipeline can reach. Security teams should be able to answer, today, how long it takes their own CI/CD vendor patches to reach every internal instance, not just the customer-facing ones. JetBrains’ own answer, in this case, was long enough to matter.
What to do now
Security teams with any exposure to JetBrains Cadence should rotate every credential class JetBrains named, audit source repositories synced through the service for unauthorized commits, and review cloud IAM activity logs for the August 8 to 24 window specifically. More broadly, any organization running TeamCity should confirm CVE-2026-63077 is patched on every instance, not just the ones a vulnerability scanner happens to reach, since JetBrains’ own experience shows that an internal, easily forgotten instance is precisely where this class of bug survives longest.
Source: JetBrains
