JetBrains Cadence Breach Exposes AWS Keys and User Data, Raising Software Supply‑Chain Fears
Attackers broke into JetBrains’ Cadence platform via an unpatched TeamCity server, grabbing AWS credentials from a backup and accessing user data and S3 files, the company says. The incident turns a single misconfigured build tool into a wider software supply-chain risk and forces customers to treat recent Cadence executions as potentially untrusted.
A lapse in patching a popular development tool has cascaded into a broader security incident for one of the software industry’s key vendors. JetBrains disclosed that attackers breached its Cadence service by exploiting an unpatched TeamCity server, then used data from a 2024 backup to obtain Amazon Web Services credentials and access customer data stored in S3 buckets.
According to the company’s account, the intrusion began with a compromise of a TeamCity instance that had not been updated against known vulnerabilities. TeamCity is widely used as a continuous integration and build server, meaning it sits close to the heart of many organizations’ software pipelines. Once inside, the attackers were able to retrieve a backup containing AWS Identity and Access Management (IAM) credentials, which they then leveraged to reach Cadence‑related resources in the cloud.
The attackers’ access reportedly included user data associated with the Cadence platform and files stored in S3 buckets. JetBrains urged customers to rotate any secrets and credentials that may have been exposed and to treat all Cadence executions as untrusted until they can be validated, a stark warning given the platform’s role in automating parts of the development lifecycle.
For development teams that rely on JetBrains tools, the breach lands uncomfortably close to their core workflow. If attackers can pivot from a build server to cloud resources and potentially tamper with or exfiltrate artifacts, then software produced during the compromised period may carry hidden risks. Even if no malicious code changes are ultimately found, the uncertainty forces security teams to spend time and resources auditing builds, logs and dependencies.
Strategically, the incident feeds growing concern over software supply‑chain security: the idea that attackers increasingly target the tools and platforms used to create code, rather than only the finished products. A vulnerable continuous integration server or misconfigured cloud snapshot can offer more leverage than a direct attack on a single application, because it provides a pathway into many downstream environments.
Cloud providers and regulators have been pressing vendors to harden build systems and to adopt practices like signed builds, stricter access controls and rapid patching of internet‑facing tools. The JetBrains case illustrates how a single unpatched component – in this case, a TeamCity server – can defeat those safeguards if it holds the keys to a wider kingdom of backups and credentials.
For customers, the most memorable lesson may be that in modern development environments, backups and build servers are not just operational conveniences; they are high‑value targets whose compromise can ripple outward silently for months. Treating them as such means subjecting them to the same, or higher, security standards as production systems.
Over the coming days, attention will focus on several concrete questions: whether JetBrains can narrow down exactly which users and artifacts were accessed; whether any evidence emerges of tampered builds being deployed into customer environments; and how quickly organizations move to rotate IAM keys, update TeamCity instances and, where possible, add extra validation checks on code and binaries produced during the affected window.
Sources
- OSINT