Security1 distinct publisher2 min readPublished
CVE-2026-63077 was in CISA's KEV catalog on August 5. JetBrains dates the intrusion into its own Cadence environment from August 8 to August 24, and every secret that touched the service now needs rotating.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
CVE-2026-63077 is a deserialization of untrusted data flaw, and the path is short: an unauthenticated attacker who can reach a TeamCity server bypasses its authentication checks and executes operating system commands with the privileges of the TeamCity server process [3]. CVSS 9.8 [2]. No credential, no user interaction, and the process it lands in is the one holding build secrets.
CISA added the flaw to the Known Exploited Vulnerabilities catalog on August 5, 2026 [4]. JetBrains dates the intrusion from August 8 [5], three days later [1]. Detection came on August 23 [6], fifteen days after the first activity it now attributes to the actor [2]. JetBrains says the server should have been patched as part of its own vulnerability response and has not said why it was not [7].
Cadence runs machine learning and heavy workloads on cloud GPUs from inside PyCharm [18], which is why the secrets sitting in it were cloud credentials. Confirmed compromised: a full 2024 backup of the Cadence server holding credentials, configuration, artifacts and logs [8], and multiple AWS IAM users with their associated secrets extracted from that backup, including IAM users belonging to JetBrains employees who used the service [9]. A backup written in 2024 and read in 2026 puts those credentials at roughly two years old [4], which matters for long-lived IAM users and not much for short-lived ones.
JetBrains' indicator list shows where the company expects those credentials to be spent: unexpected repository clones or downloads, unexpected commits, changes to repository secrets, webhooks, collaborators or permissions, new or modified personal access tokens, API tokens or SSH keys in external services, and new service accounts [13]. Those indicators point to the customer's own source control and cloud accounts, not the Cadence server itself. Six exploitation IP addresses are published [14], and they only work against logs retained from August 8 onwards [14].
Attribution is open. JetBrains says it is not clear who is behind the activity [15]. On scope, Daniel Gallo, the company's Solutions Engineering Lead, says the storage findings affect the same group of users JetBrains had already contacted directly and identified no additional affected users, with that data treated as potentially exposed [16].
For Cadence users the remediation is rotation and nothing else: api.cadence.jetbrains.com is offline, so there is no server left for them to patch [17]. Anyone running a TeamCity server reachable from the internet is in the position JetBrains was in on August 8, against an exploit that was already in KEV [4] and that worked on the company that ships the product [7].
Ranked by verification strength, evidence, and original report placement.
JetBrains urged Cadence users to immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions, and to treat all executions, including inputs and outputs, as potentially untrusted.
CVE-2026-63077 is a deserialization of untrusted data vulnerability that permits an unauthenticated attacker with access to a TeamCity server to bypass authentication checks and execute arbitrary operating system commands with the privileges of the TeamCity server process.
CVE-2026-63077 has come under active exploitation in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog on August 5, 2026.
JetBrains says the intrusion took place between August 8 and August 24, 2026, and that attackers exploited CVE-2026-63077 to breach the affected Cadence environments.
JetBrains discovered the exploitation on August 23, 2026.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 5, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Attackers exploited JetBrains' own TeamCity bug to operate inside Cadence for 16 days2 distinct publishers
build
Jenkins static AWS keys work from anywhere; the OIDC replacement fails in four known ways1 distinct publisher
build
TeamCity's new OIDC plugin turns your build server into the credential issuer1 distinct publisher
security
One packet reboots your Cisco VPN box, and Cisco will not say who is firing it1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One advisory, unusually self-incriminating
Every load figure in this story traces to JetBrains: the dates, the six IPs, the bullet list of what was 'confirmed' accessed. What lifts it above a bare vendor statement is that the advisory works against its author. It names its own discovery date, admits the server sat inside a patch programme that missed it, and concedes that AWS IAM credentials belonging to JetBrains employees were pulled out of a 2024 backup. Detail of that shape is hard to invent and easy to be caught on later. What keeps the score from going higher is that the only marker from outside the company, CISA's catalog entry, confirms the flaw was being exploited generally, not that this intrusion unfolded as described.
Containment visible, downstream response unknown
Observable action is all on JetBrains' side of the boundary: the exploited host is off the air, plugin tokens are dead, indicators are published. On the users' side there is nothing to count. No population figure for Cadence, no evidence that anyone rotated anything, no sign of whether the extracted IAM keys were exercised. Gallo's line about 'the same group of users we previously contacted directly' is the nearest thing to scope in the whole story, and it deliberately carries no number.
Reporting sits under its own evidence
The Hacker News stays inside JetBrains' register throughout, which leaves the sharpest facts sitting flat. Cloud credentials belonging to the vendor's own staff, taken from a two-year-old backup of a server the vendor admits should have been patched, appear as the third item in a bullet list, with no follow-up on whether those keys were still live or what they could reach. The scale of the ask made of users, revoke everything a job could see, is a bigger statement than the write-up's temperature suggests.
The breached party writes the record
JetBrains is the subject of this breach and also the one investigating it and telling the story. It decides what qualifies as 'confirmed', it draws the boundary of who was affected through a spokesperson quote rather than a count, and it declines to explain why a server covered by its own vulnerability response was still exposed three days after CISA started the clock. The reporting passes those judgments through with clean attribution and no challenge, which is honest practice and still leaves the company's framing intact.
Firm on timeline, thin on aftermath
The chronology and the technical mechanics hold up well: specific dates, a named CVE with a KEV entry that can be checked, an indicator list detailed enough to act on. Where confidence drops is anything requiring a second party, namely the true size of the affected group, the validity of the extracted keys, and what the actor did with S3 access. Those questions are not close to closed, and one publisher relaying one advisory cannot close them.