Attackers exploited an unpatched TeamCity server inside JetBrains Cadence, a hosted service that ran PyCharm projects on cloud compute. JetBrains confirmed that the intrusion extracted personal data, compromised a full 2024 server backup and multiple AWS IAM users, and reached files in JetBrains S3 buckets.
The September 3 final update widened the possible exposure to storage used by current Cadence users. That storage held email addresses, project source code and credentials. JetBrains found no additional affected users and did not say that data was extracted from the current storage. It has not published a user count.
A Patch Gap Opened Cadence
Cadence used JetBrains TeamCity to orchestrate cloud workloads. Its server at api.cadence.jetbrains.com remained vulnerable to CVE-2026-63077, an authentication bypass in the TeamCity agent polling protocol. An unauthenticated attacker with HTTP or HTTPS access could run operating-system commands with the privileges of the TeamCity server process.
JetBrains says every TeamCity On-Premises version was affected. It fixed the flaw in 2025.11.7 and 2026.1.3 and released a security patch plugin for TeamCity 2017.1 and later. TeamCity Cloud customers required no action because JetBrains had already applied protective measures there.
The Cadence activity began on August 8. JetBrains discovered the exploitation on August 23 and took the server offline on August 24. In the incident report, the company stated: “We have since confirmed the Cadence environment was vulnerable to CVE-2026-63077 and was exploited through this vulnerability.”
JetBrains also acknowledged the preventable operational failure. The Cadence server should have received the TeamCity patch as part of the company’s response, but it remained unpatched.
One Server Reached Many Systems
The compromised 2024 backup contained credentials, configuration, artifacts and logs. JetBrains confirmed that the attackers compromised multiple AWS IAM users and their credentials, including accounts belonging to employees who used Cadence. The actor also accessed files in S3 buckets inside JetBrains AWS accounts. JetBrains was still unable to quantify the full set of S3 data accessed.
The backup and the live service sat at the center of several trust relationships. Cadence executions could receive cloud keys, source-control tokens, registry credentials, Slack tokens, webhooks, API tokens, SSH and deployment keys, service-account credentials, and signing keys or certificates. Some users may also have configured Cadence to reach customer-owned storage buckets. JetBrains did not determine that those customer buckets were accessed.
Long description
The diagram begins with CVE-2026-63077 on the Cadence TeamCity server. One branch leads to the confirmed compromise of a 2024 server backup, then to confirmed compromise of multiple AWS IAM users and credentials found in that backup. A second branch leads to confirmed access to files in JetBrains S3 buckets. A third branch leads to current Cadence storage containing email addresses, project source code and credentials; JetBrains treated this storage as potentially exposed and did not establish extraction. A note preserves two additional limits: JetBrains did not quantify the affected user count or determine that customer-owned storage buckets were accessed.The distinction between confirmed access and precautionary exposure is important. Personal data was extracted from the affected environment, while the current-storage finding established access that could have reached code and credentials. JetBrains treated that current data as exposed because the investigation could not rule out access.
Recognition Starts With Identity History
JetBrains tied observed exploitation to 150[.]109[.]230[.]104, 43[.]153[.]227[.]206, 62[.]210[.]127[.]48, 210[.]247[.]242[.]190, 15[.]235[.]225[.]205 and 152[.]233[.]30[.]18. Review authentication and activity from those addresses from August 8 onward, especially when the identity previously stored a secret in Cadence or made it available to a Cadence execution.
The wider hunt should connect identity events with repository and cloud activity. Look for unexpected logins or locations, repository clones or downloads, unauthorized commits, changed repository secrets, new webhooks or collaborators, and new personal access tokens, API tokens, SSH keys or service accounts. In cloud logs, review IAM role or policy changes and unexpected reads of buckets or objects. Package and release publication also belongs in the same timeline.
These addresses and behaviors are scoping aids. JetBrains says its indicator list is not exhaustive, and the absence of a match does not establish that an account or system was unaffected. The company offers contacted users an inventory of credentials associated with their Cadence use, but warns that this inventory is incomplete too.
Recovery Follows Every Stored Secret
Former Cadence users should revoke or rotate every credential that entered the service, appeared in synchronized project files, lived in the 2024 backup or was available to an execution. That includes cloud, source-control, package and container-registry credentials alongside deployment keys, signing material, webhooks and service accounts. JetBrains invalidated Cadence plugin access tokens, yet that action cannot revoke credentials held by connected systems.
Treat Cadence inputs and outputs as potentially untrusted. Review AWS, Azure and Google Cloud accounts; S3 and other storage; GitHub, GitLab and Bitbucket repositories; deployment environments; package registries; and container registries. Inspect repositories for unauthorized changes, then compare the user-specific JetBrains credential inventory with local secret stores, build configuration and execution history.
A source-backed verification test starts with the August 8 to August 24 exposure window and extends forward for any credential that was not immediately revoked. The expected result is that connected identity, repository, cloud, storage and publication logs show no unauthorized access or changes, while every exposed credential has a recorded replacement and the old value no longer authenticates.
The incident shows why a hosted build service belongs in credential-recovery plans even after the service itself is offline. Cadence connected code, cloud authority and delivery systems in one execution environment. Recovery has to follow those trust paths until each old credential and each resulting change has been accounted for.