JetBrains announced that the TeamCity instance behind its Cadence cloud development service was never patched for the critical CVE‑2026‑63077 flaw, allowing unauthenticated attackers to run OS commands and compromising the service from 8 August to 24 August.
TeamCity server breach
The vulnerability permits any HTTP/HTTPS client to execute commands with the same privileges as the TeamCity process. JetBrains disclosed the CVE on 27 July and warned that attackers were already exploiting unpatched servers by 7 August. The company’s own server, which orchestrates Cadence workloads, was missed during the remediation effort and remained exposed. Attackers accessed api.cadence.jetbrains.com, extracted a 2024 backup, and harvested AWS IAM users, S3 objects, and a range of development‑related secrets.
Why it matters to CI/CD and cloud engineers
Cadence sits at the intersection of source control, cloud compute, and artifact publishing. A compromised orchestrator can leak credentials for AWS, Azure, GCP, GitHub, GitLab, Bitbucket, npm, Maven, NuGet, PyPI, Docker Hub, ECR, GCR, and ACR. Those secrets enable lateral movement into customer accounts, unauthorized package publication, and potential supply‑chain attacks. Moreover, any build artefacts produced during the breach window may have been altered, breaking the trust model that CI/CD pipelines rely on.
Architectural and operational implications
Practitioners should treat the Cadence service as a single point of failure for secret handling. The incident highlights the need for:
- Immediate rotation of all cloud‑provider keys, service‑account tokens, and repository access tokens that were ever used in Cadence executions.
- Segregation of privileged credentials from build agents, preferably using short‑lived, scoped tokens.
- Regular verification that backup data containing secrets is stored encrypted and isolated from production workloads.
- Comprehensive audit of source‑control logs for unexpected clones, commits, or webhook changes, and cloud‑provider logs for new IAM users, role modifications, and anomalous S3 access.
- Validation of artefacts generated during the affected period against known good hashes or reproducible builds.
Because Cadence integrates via an optional PyCharm plugin, developers may have unintentionally uploaded project files containing embedded credentials. Teams must therefore review project‑level configuration files for accidental secret leakage.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Actionable steps include:
- Revoke and re‑issue every AWS, Azure, and GCP credential that appeared in Cadence logs or backups.
- Rotate tokens for all supported source‑code hosts and package registries.
- Mark all Cadence builds from 8 August to 24 August as untrusted; rebuild critical artefacts from clean sources.
- Run a focused audit of IAM changes, S3 bucket access patterns, and source‑control activity for the same window.
- Implement automated secret‑scanning and short‑lived credential issuance for future CI/CD jobs to reduce blast radius.
Until the full scope is known, assume that any downstream system that accepted Cadence‑issued credentials may have been accessed. Continuous monitoring and rapid credential turnover are essential to limit exposure.


