Start with Identity
← Blog
News

JetBrains was breached through an unpatched copy of its own TeamCity

Attackers exploited CVE-2026-63077 against a JetBrains-run TeamCity server to breach the Cadence cloud service, taking AWS IAM credentials, source code, and secrets from a 2024 backup. JetBrains says the server should have been patched.

By SWI Community TeamSep 5, 2026Updated Sep 14, 2026

Between August 8 and August 24, 2026, attackers exploited CVE-2026-63077, the unauthenticated TeamCity flaw disclosed in July, against a JetBrains-operated TeamCity server and used it to reach the Cadence cloud compute service. They accessed a 2024 Cadence server backup containing usernames, real names, email addresses, last-login timestamps, last-seen IP addresses, multiple AWS IAM credentials, project source code, configuration files, and stored secrets, plus files in S3 buckets in JetBrains AWS accounts. JetBrains detected the activity on August 23 and concluded its investigation on September 3, confirming the additional cloud storage exposure. api.cadence.jetbrains.com was taken offline. The company acknowledged the server should have been patched under its own vulnerability response process and did not explain why it was not. Cadence users are told to rotate every credential used in their executions.

Why it matters

We covered CVE-2026-63077 on July 27, when the note was that every on-premises TeamCity server was vulnerable. It turns out that included JetBrains'. There is no schadenfreude worth extracting here, because the failure is the ordinary one: an asset that belonged to no team's patching scope, running a product the organization knows better than anyone.

The durable lesson is about the backup. The breach reached a 2024 snapshot, which means credentials created two years earlier were still live and still useful in August 2026. Backups inherit the secrets of the moment they were taken and then sit outside every rotation process anyone runs. If your rotation covers production but not the snapshots of production, your effective credential lifetime is the age of your oldest retained backup.

Concretely: include backup and snapshot stores in the blast radius when you rotate, prefer short-lived credentials that expire inside a backup rather than long-lived IAM keys that do not, and inventory the internet-facing instances of your own products the same way you inventory a vendor's.

Source: The Hacker News

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Independent analysis. No vendor sponsorship.