Between August 8 and August 24, 2026, attackers walked into JetBrains' own Cadence cloud build service through a front door JetBrains had already told its customers to lock. The vulnerability, CVE-2026-63077, is a critical unauthenticated remote code execution flaw in TeamCity On-Premises, disclosed in July and added to CISA's Known Exploited Vulnerabilities catalog on August 5 after active exploitation was observed in the wild. JetBrains patched it for customers. It did not patch the internal TeamCity server sitting behind its own Cadence service, and that server is exactly what attackers used to get in.
The irony is easy to reach for, but the useful part of this story is not that a security-conscious vendor missed a patch window. It is that this happens constantly, to organizations with far less discipline around CI/CD than JetBrains has, and it mostly does not make the news because nobody notices until the fallout shows up somewhere else. A build server compromise is quiet by design. It does not throw errors in production, it does not page anyone, and it hands an attacker exactly the kind of access that turns one bad patch cycle into a multi-week breach with source code, credentials, and customer data walking out the door.
The timeline matters because every step in it is a decision point that a different process would have caught. CVE-2026-63077 is a deserialization-of-untrusted-data vulnerability: an attacker with plain HTTP or HTTPS access to a vulnerable TeamCity server can submit crafted data that the server deserializes into live objects, and those objects execute arbitrary operating system commands with the privileges of the TeamCity process itself. No authentication is required. If your TeamCity server answers requests on a reachable network, an attacker does not need a password, a phished session, or a stolen token. They need the URL.
JetBrains discovered the exploitation on August 23, sixteen days after the exploit window opened, and took the affected server offline the next day. By the time it did, attackers had extracted usernames, real names, email addresses, last-login timestamps, last-accessed IP addresses, and multiple AWS IAM credentials. They also reached project source code, configuration files, and secrets preserved in a 2024 backup of the Cadence server, along with files sitting in S3 buckets inside JetBrains' own AWS accounts. That is not a narrow data-privacy incident. It is the full contents of a build system: identity data, cloud credentials, and code, all reachable from one unpatched entry point.
Java deserialization vulnerabilities are a well-understood, decades-old vulnerability class, not a novel attack technique that caught the industry off guard. Gadget chains that turn deserialization into remote code execution have been public knowledge since at least the mid-2010s, and TeamCity itself has had prior CVEs in the same family. None of that made this exploit harder to pull off once the patch window was missed. The lesson is not "deserialization is dangerous," which every application security team already knows. It is that knowing a vulnerability class is dangerous does not protect you if the specific patch for the specific instance running in your own infrastructure sits un-applied for weeks.
Security teams spend enormous effort hardening production. CI/CD infrastructure routinely gets a fraction of that attention, despite sitting at a chokepoint with more leverage than almost anything else in the stack. A few properties make that gap dangerous.
Unauthenticated RCEs in CI/CD tooling do not sit unpatched for weeks because nobody knows about them. JetBrains published the advisory itself. The gap between disclosure and exploitation exists because of an ownership problem that shows up in almost every organization we have reviewed: internal developer tooling does not clearly belong to the security team, the platform team, or the individual engineering teams that use it day to day, so patching cadence for it defaults to whenever someone gets around to it rather than a defined SLA. Production services get patched on a schedule because an outage or a breach there is visible and immediately attributable. A TeamCity or Jenkins instance living on an internal network gets patched when someone remembers, because the cost of not patching it is invisible until the day it is not.
CVE-2026-63077 required only HTTP or HTTPS access to a vulnerable server, which means the single highest-leverage control available to any team running TeamCity, Jenkins, GitLab CI runners, or any equivalent tool is a simple question: can this server be reached from the open internet at all? A CI/CD server does not need to be internet-facing for engineers to use it. VPN access, a private network with bastion access, or a zero-trust access proxy in front of the build system all remove an entire class of unauthenticated exploits from being reachable in the first place, independent of whatever patch level the server happens to be running. Patching matters. Not being reachable matters more, because it buys you the weeks a patch cycle actually takes.
None of the following requires a platform rebuild. Each of these is something a team can start this quarter, in roughly the order that gives the fastest reduction in blast radius.
The uncomfortable takeaway from the JetBrains Cadence breach is not that TeamCity has a vulnerability, every piece of software eventually does. It is that an organization whose entire business is developer tooling still let a disclosed, actively exploited, unauthenticated RCE sit unpatched on its own infrastructure for over two weeks. If that gap can open inside JetBrains, it is almost certainly open somewhere in your own CI/CD footprint right now, whether that is an internet-reachable Jenkins controller, a set of long-lived AWS keys sitting in a pipeline environment variable, or a build server nobody has checked the patch level on since it was stood up. Start with the internet exposure question, since it is the fastest fix with the largest blast-radius reduction, then work down the checklist above. If you want an outside set of eyes on where your own build and deployment pipeline would fail this exact test, our IT consultancy practice runs infrastructure security reviews built around precisely this kind of scenario, before it becomes your incident report instead of JetBrains'.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.