CTIPilot
← Back to the live brief
HIGHCVE-2026-63077exploitedNATOA2incident

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: our Cadence service should have been patched against our own CVE-2026-63077 advisory, it wasn't, and attackers used it for 16 days

Defender actions

  • Any organization that used JetBrains Cadence must revoke and rotate every credential and secret ever used in a Cadence execution, cloud (AWS/Azure/GCP), source-control, package-registry, container-registry, Slack, SSH/deployment keys and signing material, and review connected AWS accounts, S3 buckets and source repositories for unauthorized access or changes during 2026-08-08 to 2026-08-24.
  • Anyone who synchronized PyCharm project files to Cadence for execution must treat that source code, and any credentials or configuration it contains, as compromised and audit repositories for unauthorized changes made during the affected period.

Analysis

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.

Cited evidence

We have since confirmed the Cadence environment was vulnerable to CVE-2026-63077 and was exploited through this vulnerability.

The server should have been patched as part of our response to the vulnerability, but it was not. We sincerely apologize for this failure and the impact it may have on you.

Compromised multiple AWS IAM users and associated credentials/secrets used with Cadence, including IAM users belonging to JetBrains employees who used the service.

We have confirmed that the threat actor accessed data contained in the Cadence server backup from 2024.

JetBrains (PyCharm Blog) 2026-09-03

Sources3

PROVENANCE

AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.