JetBrains is telling users of its Cadence cloud development service to rotate all credentials and treat prior executions as compromised after attackers exploited a critical TeamCity vulnerability on a server the company neglected to patch. The software maker disclosed CVE-2026-63077, a critical flaw in TeamCity On-Premises, on July 27 and warned by August 7 that attackers were actively exploiting unpatched servers. But JetBrains left its own Cadence server vulnerable, and attackers struck it on August 8—just one day after the company's exploitation warning.
The breach ran from August 8 to August 24, when JetBrains finally took the server offline after discovering the attack on August 23. Attackers targeted api.cadence.jetbrains.com, the infrastructure behind Cadence, JetBrains' cloud compute service for PyCharm that lets developers run projects on remote resources through an optional plugin. The compromised server sat behind that service, orchestrating workloads in a particularly sensitive part of the development environment. Attackers obtained a complete Cadence server backup from 2024, potentially exposing credentials, configuration files, artifacts, and logs stored within it. Multiple AWS IAM users and their associated credentials were compromised, including IAM users belonging to JetBrains employees who had used Cadence. Attackers also accessed files in S3 buckets within JetBrains AWS accounts used by the service, though the company hasn't yet determined whether customers' storage buckets were accessed. The breach exposed usernames, real names, email addresses, last-login timestamps, and last-accessed IP addresses. Developers who synced project files to Cadence before running them may have had source code and any credentials or configuration files included with those projects exposed as well.
"The server should have been patched as part of our response to the vulnerability, but it was not," JetBrains acknowledged in its disclosure of the incident. The company says users should consider any credentials or secrets stored in Cadence, included in the compromised backup, or used during an execution to be compromised. That encompasses AWS, Azure, and Google Cloud credentials, tokens for GitHub, GitLab, and Bitbucket, and credentials for npm, Maven, NuGet, PyPI, and container registries such as Docker Hub, ECR, GCR, and ACR. According to the report, access to those registries creates supply chain risk—an attacker with publishing credentials could push a malicious package that gets pulled into other projects. The warning also covers Slack tokens, webhooks, API tokens, SSH and deployment keys, service account credentials, and signing keys or certificates.
The report explains that CI/CD and remote execution systems often have access to private repositories, dependencies, cloud storage, package registries, and deployment systems, making their central role in software delivery a target for attackers seeking lateral movement into connected environments. Once the environment itself has been compromised, developers can't assume the credentials that passed through it or the artifacts it produced are safe. JetBrains says the concern isn't limited to exposed data and credentials—anything Cadence ran during the affected period, including the resulting output, should also be treated as untrusted because it could potentially have been altered. The company published six IP addresses associated with detected exploitation but warned that these indicators aren't complete, so not seeing them doesn't mean an account or system wasn't compromised.
JetBrains recommends checking source control audit logs for unexpected repository clones or downloads, unauthorized commits, and changes to repository secrets or webhooks, as well as looking for new or changed personal access tokens, API tokens, and SSH keys. Cloud environments need the same careful review—users should look for unexpected IAM changes, new users or service accounts, and unusual access to storage like S3 buckets, while authentication logs can show if credentials used in Cadence were later used from unknown locations. Package repositories and release histories should be checked for unexpected publications or changes, especially where Cadence had credentials that could publish packages or artifacts. Developers may also need to review artifacts made through the service during the affected period to ensure they match trusted source code and expected build results. The episode illustrates how quickly trust boundaries collapse when a development platform is breached, forcing teams to verify not just what was stolen but whether anything they built during that window can still be trusted. Companies that position themselves as security authorities face steeper reputational costs when their own infrastructure falls to the very threats they're warning customers about.