Cadence is a JetBrains-hosted cloud service that plugs into PyCharm and runs machine learning and other heavy workloads on cloud GPUs, straight from the IDE.

Its server, api.cadence.jetbrains.com, was running an unpatched TeamCity.

The three dates

5 August 2026 — CISA adds CVE-2026-63077 to the Known Exploited Vulnerabilities catalogue. It is a deserialization flaw, CVSS 9.8, allowing an unauthenticated attacker to bypass authentication and run arbitrary OS commands with the privileges of the TeamCity server process.

8 August 2026 — attackers exploit it on the Cadence server. The intrusion runs to 24 August.

23 August 2026 — JetBrains discovers it.

Three days from public confirmation of in-the-wild exploitation to compromise. Fifteen days from compromise to detection.

Be fair about the three days

Three days is not, on its own, a scandal. Patching a real estate takes change windows, dependency checks and someone to do it, and plenty of competent organisations were still working through this one on 8 August.

The asymmetry is what makes it worth writing about. JetBrains makes TeamCity. During those three days the company was telling its customers to patch this flaw urgently, and its own hosted service was running the unpatched version. The knowledge was not the constraint; nobody had to wait for an advisory to reach them.

JetBrains has not said why the server was not patched, and that is the single most useful thing it could still publish. Most organisations that get caught this way have the same answer — the box belonged to a team that did not know it was in scope — and hearing a vendor say so out loud would help more people than another advisory.

What left the building

This is where it stops being an embarrassment and starts being a problem for other people.

  • Personal data: usernames, real names, email addresses, login timestamps, IP addresses
  • A full 2024 Cadence server backup, containing credentials, configuration, artifacts and logs
  • Multiple AWS IAM users and their credentials and secrets, including some belonging to JetBrains employees
  • Files from S3 buckets inside JetBrains AWS accounts
  • Source code synchronised from users' PyCharm projects

Two of those deserve to be pulled out.

The backup is the real damage. A 2024 server backup is a time capsule of secrets, and a secret in it is live unless somebody has rotated it since. Most organisations rotate on incident, not on schedule, which means the useful assumption is that anything in that backup still works.

Users' source code was taken. People pointed their IDE at a GPU service and their projects went with it. If your organisation used Cadence, your code was in scope of somebody else's breach and you would have had no way to know.

Read the advice JetBrains gave

Cadence users should immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions. They should also treat all executions, including their inputs and outputs in your Cadence project, as potentially untrusted.

The first sentence is a normal credential rotation notice.

The second is a supply-chain warning inside a breach notice. Treat your outputs as potentially untrusted means: an attacker had command execution on the machine that produced your results, so anything that came back from it — model artifacts, generated code, computed data — might have been altered. Anyone who took a Cadence output and shipped it needs to reason about that, and there is no tooling that will tell them.

The PaperCut intrusions last week ended in exactly the same place: the interesting thing about a compromised server is rarely the server, it is the credential material sitting on it that reaches somewhere else.

What to do

  • If you used Cadence, rotate everything that touched it, and do not scope that to the credentials you deliberately configured. The backup predates whatever you think you exposed.
  • Check your AWS accounts for access originating from JetBrains-associated credentials. IAM users in the backup are the pivot.
  • Treat any artifact produced by a Cadence execution as suspect if it went anywhere near production. JetBrains said so; take it literally.
  • Then go and find your own TeamCity servers. CVE-2026-63077 is in KEV, it is unauthenticated, and it is 9.8. The lesson from this incident is not about JetBrains — it is that the inventory of who runs your build servers is usually wrong.
  • Ask where your CI backups live and who can read them. That is the asset that turned a server compromise into a credential compromise here.

What is not established

  • Who did it. No attribution has been published.
  • Why the server was unpatched. JetBrains has not said.
  • The full extent of AWS access achieved with the extracted credentials.
  • Whose source code was taken, or how much. JetBrains has described the category, not the scope.
  • Whether anything was modified, as opposed to read. The advice to treat outputs as untrusted implies the question is open, not that the answer is known.