JetBrains Cadence Breach Exposed Developer Data, AWS Credentials and Source Code

• The Mess: Attackers exploited CVE-2026-63077 in JetBrains TeamCity to break into the Cadence cloud service and access customer data, a 2024 server backup, AWS credentials and files synchronized from PyCharm projects.
• The Damage: Developers who used Cadence may have exposed cloud credentials, GitHub tokens, package-registry secrets, SSH keys and source code to an attacker.
• The Fix: Revoke and rotate every credential that was stored in or accessible through Cadence, then investigate connected cloud accounts, repositories, package registries and deployment systems.

This wasn’t a breach of somebody’s marketing database.

It hit a service sitting directly inside the developer workflow.

JetBrains Cadence was compromised after attackers exploited a critical TeamCity vulnerability, gaining unauthorized access to the cloud service used to execute projects from PyCharm.

JetBrains has now confirmed that customer data was exposed.

And the interesting part isn’t just the names and email addresses.

It’s what developers were allowed to connect to Cadence.

The Entry Point Was TeamCity

The incident revolves around CVE-2026-63077, a critical TeamCity vulnerability that can allow an unauthenticated attacker to execute arbitrary commands on a vulnerable server.

Cadence used JetBrains TeamCity to orchestrate its workloads.

The Cadence server at:

api.cadence.jetbrains.com

was vulnerable.

Attackers exploited it.

JetBrains says malicious activity was identified beginning August 8, 2026.

The company discovered the exploitation on August 23 and took the affected server offline on August 24.

That’s a roughly two-week window between the beginning of the observed activity and containment.

The Attacker Got More Than a User Database

JetBrains confirmed that attackers accessed and extracted personal data from the affected environment.

The confirmed information includes:

• usernames
• real names
• email addresses
• last-login timestamps
• last accessed IP addresses

That alone creates a phishing and impersonation problem.

But it isn’t the most dangerous part.

The attackers also compromised a full Cadence server backup from 2024.

That backup potentially contained:

• credentials
• configuration
• artifacts
• logs
• other server data

JetBrains says the backup must be treated as potentially exposed.

A three-year-old backup can still be extremely valuable if credentials or configuration contained inside it were reused.

AWS Credentials Were in the Blast Radius

This is where the incident becomes much more interesting for security teams.

JetBrains confirmed that multiple AWS IAM users and associated credentials/secrets used with Cadence were compromised.

Some belonged to JetBrains employees who used the service.

Those credentials were present in the compromised 2024 backup.

The attackers also accessed files stored in S3 buckets inside JetBrains AWS accounts used by Cadence.

JetBrains is still determining the complete scope of that access.

The company has not confirmed that attackers accessed customer-owned storage buckets.

But there is a nasty possibility.

Some Cadence users configured the service to access their own cloud storage.

If those connections used credentials that were exposed through Cadence, the attack could extend beyond JetBrains’ infrastructure.

Your PyCharm Project May Be Part of the Problem

Cadence integrates with PyCharm through an optional plugin.

The service allows developers to synchronize projects and run them using cloud compute resources.

That means project files can end up inside the Cadence environment.

JetBrains warns that source code synchronized from PyCharm projects to the affected server may have been accessed.

Developers should therefore treat that code as potentially compromised.

And they should do the same with credentials or configuration contained inside those projects.

That last part matters.

Developers still put secrets in configuration files.

Sometimes they put them in environment variables.

Sometimes they accidentally commit them.

Sometimes they pass them directly to build and execution environments.

If those values were available to a compromised Cadence execution, assume they are gone.

The List of Credentials Is Ugly

JetBrains explicitly recommends rotating credentials that were stored in Cadence, present in the compromised backup or made available to executions.

That includes:

Cloud credentials

AWS, Azure and Google Cloud.

Source-control credentials

GitHub, GitLab and Bitbucket.

Package repositories

npm, Maven, NuGet, PyPI and similar services.

Container registries

Docker Hub, Amazon ECR, Google GCR, Azure ACR and others.

Infrastructure credentials

SSH keys, deployment keys, service accounts and API tokens.

Communication systems

Slack tokens and webhooks.

Cryptographic material

Signing keys and certificates.

That’s not a normal password-reset exercise.

It’s a developer infrastructure incident.

The Attack Can Move Sideways

Imagine a developer used Cadence to run a project.

That project had access to:

AWS → S3 → deployment infrastructure

or:

GitHub → package registry → production build

or:

SSH → deployment server

If the attacker obtains the credentials involved, the original Cadence compromise becomes only the first step.

The attacker can leave Cadence entirely.

They can move into systems that trusted the compromised credentials.

That’s why JetBrains recommends reviewing connected systems, not just the Cadence server itself.

JetBrains Published Indicators of Compromise

JetBrains says potentially suspicious activity should be reviewed from August 8, 2026 onward.

The company also published several IP addresses associated with observed exploitation activity:

• 150.109.230.104
• 43.153.227.206
• 62.210.127.48
• 210.247.242.190
• 15.235.225.205
• 152.233.30.18

Administrators should also investigate:

• unexpected repository clones
• unexpected downloads
• unauthorized commits
• modified repository secrets
• new webhooks
• changed collaborators
• new API tokens
• new SSH keys
• unexpected service accounts
• modified cloud IAM permissions
• unexpected S3 access
• unexplained package publications

JetBrains explicitly warns that its IoCs are not exhaustive. Absence of one of the listed indicators does not prove that an account or system was unaffected.

JetBrains Has Shut the Server Down

JetBrains took the affected Cadence server offline on August 24.

The company also invalidated access tokens used by the Cadence plugin in PyCharm to connect to the service.

The server was patched as part of the response.

But JetBrains acknowledged an uncomfortable failure:

the server should have been patched earlier, and it wasn’t.

That is particularly important because CVE-2026-63077 was already known as a critical TeamCity vulnerability.

A vulnerable infrastructure component ended up becoming the entry point into a service holding developer-related data and credentials.

Today’s Update Is Better News — But Not a Clean Bill of Health

JetBrains updated the incident notice on September 1.

The company says its investigation is now nearing completion and most mitigation and response actions have been finalized.

It has not identified additional compromised resources or data since the previous update.

But that doesn’t mean affected users can stop rotating credentials.

The recommended actions remain unchanged.

This Is Why Developer Platforms Are High-Value Targets

Attackers don’t necessarily need to compromise GitHub.

They don’t necessarily need to break AWS.

They don’t necessarily need to steal an npm account directly.

Sometimes they can attack the service sitting between the developer and those systems.

Cadence was one of those bridges.

It could execute projects.

It could interact with external infrastructure.

It could handle credentials.

It could access project files.

That makes it an attractive target.

The Real Problem Is Trust

The breach demonstrates a familiar security problem.

A developer sees:

PyCharm → Cadence → cloud execution

Security teams may see:

developer workstation → third-party service → CI/CD → cloud → source control → package registry

That’s a huge trust chain.

Every component in that chain becomes another potential attack surface.

CVE-2026-63077 was enough to break one of those links.

Bugstoday Opinion

This is exactly the kind of breach developers should worry about.

Not because someone stole a list of email addresses.

Because the compromised service sat in the middle of the development pipeline.

A compromised developer platform can become a credential warehouse.

AWS keys.

GitHub tokens.

npm credentials.

SSH keys.

Cloud access.

Source code.

Deployment secrets.

The attacker doesn’t have to break into every system separately if the credentials connecting those systems are already sitting inside one compromised environment.

Bugstoday verdict: Cadence turned a TeamCity vulnerability into a developer-infrastructure incident. If you used Cadence during the affected period, assume secrets are compromised until proven otherwise. Rotate them, inspect your cloud and source-control logs, and don’t confuse “JetBrains shut down the server” with “the attacker’s access disappeared everywhere.”

Today’s Bugs. Tomorrow’s Breaches.

Sources

• JetBrains Security — Security Incident Affecting JetBrains Cadence
• JetBrains Security — CVE-2026-63077
• JetBrains PyCharm — Cadence Security Incident
• JetBrains — Cadence Documentation
• MITRE CVE — CVE-2026-63077