JetBrains TeamCity On-Premises

JetBrains admits its own Cadence cloud-compute service ran unpatched against a KEV-listed vulnerability it had disclosed a month earlier, and was breached through it for sixteen days

JetBrains disclosed, in an incident notice last updated 2026-09-03, that its Cadence cloud-compute service (a JetBrains-hosted offering integrated with PyCharm through an optional plugin, letting developers run projects on JetBrains-managed cloud compute) was compromised via CVE-2026-63077 (JetBrains, 2026-09-03). That CVE is a deserialization flaw in JetBrains TeamCity, which Cadence used internally to orchestrate workloads, letting an unauthenticated attacker execute arbitrary operating-system commands with TeamCity server-process privileges; The Hacker News's coverage of the KEV listing puts it at CVSS 9.8 (The Hacker News, 2026-09-05). JetBrains itself disclosed CVE-2026-63077 in July 2026 (JetBrains TeamCity PSIRT, 2026-07-27), and CISA added it to the Known Exploited Vulnerabilities catalog on 2026-08-05 after observing active exploitation elsewhere (The Hacker News, 2026-09-05). Despite owning that advisory, JetBrains admits the Cadence server (api.cadence.jetbrains.com) was never patched against it: "the server should have been patched as part of our response to the vulnerability, but it was not" (JetBrains, 2026-09-03). Exploitation activity ran from 2026-08-08 to 2026-08-24; JetBrains discovered it on 2026-08-23 and took the server offline the next day.

Confirmed impact spans several categories. Threat actors accessed and extracted personal data for the affected user cohort: usernames, real names, email addresses, last-login timestamps and last-accessed IP addresses. They compromised a full 2024 backup of the Cadence server, meaning any credentials, configuration, artifacts or logs present in that backup must be treated as potentially exposed. They compromised multiple AWS IAM users and their associated credentials, including IAM users belonging to JetBrains employees who used the service, extracted from that same 2024 backup (JetBrains, 2026-09-03). They accessed files stored in S3 buckets within JetBrains's own AWS accounts used by Cadence, with the full scope still under investigation; JetBrains states it does not currently know whether customer-account storage buckets were reached, though some users had configured Cadence to access their own buckets, exposing those connection credentials too. Finally, source code synchronized from PyCharm projects to the affected server may have been accessed, and JetBrains instructs anyone who used that sync path to treat the code, and any embedded credentials or configuration, as potentially compromised. JetBrains has invalidated all Cadence plugin access tokens and is notifying relevant authorities.

The root-cause lesson generalizes past this one vendor: a vendor's own KEV-listed, self-disclosed CVE went unpatched on its own production infrastructure for the better part of a month after publication. Patch-SLA enforcement has to apply to internally- or vendor-hosted CI/CD infrastructure with the same urgency as the advisory a vendor ships to its customers; the exposure here was JetBrains's own build orchestration server, not a customer's.

Detection concept, telemetry class first: on any self-hosted TeamCity instance (Cadence's own root cause), web-server or reverse-proxy access logs showing requests to the agent-polling endpoint from addresses outside the registered build-agent fleet are the first signal, and process-creation telemetry showing the TeamCity server process spawning a shell, interpreter or network utility outside a build step is the second, more decisive one, see the original CVE-2026-63077 entry's Detection section for the full discriminator. For any organization that used Cadence specifically: cloud audit-log review for authentication or IAM/role-policy changes from unexpected addresses since 2026-08-08, unexpected S3 object access in JetBrains-adjacent or connected AWS accounts, and unexpected commits, new personal-access-tokens or new service accounts appearing in source-control and package-registry systems that ever received a credential through a Cadence execution.

Builds on: 2026-07-29/cve-2026-63077-teamcity-onprem-unauth-deserialization-rce

CVE-2026-63077, JetBrains TeamCity On-Premises: unauthenticated RCE through the agent-polling protocol, every on-prem version affected (CVSS 9.8)

JetBrains' advisory is short on mechanism by design and unambiguous on reach: an unauthenticated attacker with HTTP(S) access to a TeamCity On-Premises server can bypass authentication checks and run arbitrary operating-system commands with the privileges of the TeamCity server process, and every On-Premises version ever shipped is affected (JetBrains, 2026-07-27). The reachable surface is the agent-polling protocol, the channel distributed build agents use to check in with the central server for job assignments and configuration. JetBrains' own framing is that exploitation of the flaw requires no authentication and that the attacker bypasses authentication checks by way of that protocol, so there is no credential, session, or user interaction standing between a network-reachable server and command execution (JetBrains, 2026-07-27). The flaw was reported privately on 2026-07-10 by Antoni Tremblay, and JetBrains states it is not aware of any active exploitation as of publication (JetBrains, 2026-07-27); the CVE record filed by JetBrains as its own CNA carries the flaw as CWE-502, deserialization of untrusted data, at CVSS 9.8 (MITRE CVE Record, 2026-07-27).

The reason this warrants moving ahead of the ordinary patch queue is what a build server is, not the score. A TeamCity server holds the credentials its pipelines deploy with, the signing material its artifacts are stamped with, and write access to the outputs every downstream consumer trusts, so command execution as the server process converts into a durable ability to alter what future builds produce. Public exploitation of the present flaw has not been observed, and the honest reading of that is a clock rather than an all-clear, JetBrains withheld the gadget chain, but "all versions affected" plus "no authentication" plus a widely deployed, easily fingerprinted product is a combination that historically closes quickly once someone reconstructs the path.

Detection: the observable is in the web-server or reverse-proxy access log in front of TeamCity and in process-creation telemetry on the server host. Requests to the agent-polling endpoint arriving from addresses that are not your registered build agents are the first signal, and the second (the one that matters if the first was missed) is any child process spawned by the TeamCity server process that is not part of a build it was asked to run: shells, interpreters, or network utilities parented to the server rather than to an agent's build step. Triage: the agent-polling endpoint legitimately receives continuous check-in traffic from your build fleet, so request volume to it discriminates nothing on its own. Two things do. The source address set is finite and knowable; your registered agents are an inventory, so polling traffic from anything outside it is the anomaly. And on the server host, legitimate command execution belongs to agent processes running build steps; the server process itself spawning an interpreter or a network utility is not a quieter version of normal activity but a different thing entirely. Hardening: apply 2025.11.7 or 2026.1.3, or the security-patch plugin on 2017.1 and later, and treat the agent-polling interface as an internal service, if the only reason it faces the internet is that some agents live outside the network, a VPN or reverse tunnel for those agents removes the exposure that makes this flaw reachable at all.