We wrote about CVE-2026-63077 in early August, when it was a JetBrains TeamCity advisory with an unusually candid line in it: the company said it had no evidence of active exploitation at the time it shipped the patch on 27 July. Nine days later, on 5 August, CISA added the same CVE to its Known Exploited Vulnerabilities catalog, which meant someone, somewhere, had already found a way to make that "no evidence" statement stop being true. What we didn't know then is that three days after CISA's KEV addition, on 8 August, attackers began using that exact flaw against a TeamCity server JetBrains itself was running - one that fed into Cadence, its own cloud compute product. The Hacker News' account of the disclosure lays the timeline out end to end, and it is not a flattering one for the company that told the rest of the industry to move fast on this bug.
Sixteen days inside, before anyone noticed
Per JetBrains' own disclosure, the intrusion ran from 8 August to 24 August - sixteen days - before the company discovered the exploitation on 23 August and pulled the affected server offline the following day. Rescana's summary of the incident is blunt about the mechanism: attackers used CVE-2026-63077's authentication bypass to reach the TeamCity server directly, then moved from there into the Cadence environment it was connected to. The public disclosure didn't land until 5 September, roughly a fortnight after the server came down - a gap JetBrains hasn't explained beyond the time needed for investigation.
What actually left the building
The exposure runs wider than a typical credentials leak. Per JetBrains' notice, attackers pulled account data for Cadence users - usernames, real names, email addresses, last-login timestamps and last-accessed IP addresses - alongside a full backup of the Cadence server dated 2024, containing its own stored credentials, configuration files and secrets. Multiple AWS IAM user credentials tied to JetBrains' own AWS accounts came out with it, along with files from S3 buckets in those accounts. JetBrains has told Cadence users to "immediately revoke or rotate all credentials and secrets" and to treat everything that ever ran through a Cadence project - inputs and outputs alike - as potentially exposed, which is about as broad a precaution as a vendor can ask for without confirming the worst case outright.
The same bug, a second time, closer to home
What makes this worth returning to isn't a new vulnerability - it's the same one we already flagged, landing on the vendor's own infrastructure. Our original coverage made the point that a compromised build server holds the keys to everything it deploys; JetBrains' incident is that argument playing out against the company that builds the tool, not a customer running it. It also complicates the "no evidence of exploitation" framing vendors routinely use at disclosure - not because JetBrains was wrong to say it in July, but because the gap between a vendor's visibility and an attacker's head start turned out, in this case, to run through JetBrains' own network.
What to do if you use Cadence, or TeamCity, or both
- If you have a Cadence account, rotate every credential and secret associated with it now, and treat any 2024-era secret you haven't rotated since as compromised.
- Audit AWS IAM credentials and S3 access tied to any integration with JetBrains services for unusual activity going back to early August.
- Confirm every TeamCity On-Premises instance you operate is on 2025.11.7, 2026.1.3 or later - if you haven't upgraded since our original coverage, this incident is the reason not to wait any longer.
- Treat any code, configuration or output that passed through a Cadence project during the exposure window as potentially seen by a third party, per JetBrains' own guidance.
- Where possible, avoid storing long-lived cloud credentials inside CI/CD-adjacent services at all - this incident is as much an argument for short-lived, scoped tokens as it is for faster patching.
A vendor getting breached through the exact bug it told customers to patch is an uncomfortable story to publish about a company whose tools half the industry relies on daily, but the lesson isn't really about JetBrains specifically - it's about how thin the margin is between "we patched it" and "we patched it everywhere, including the corner of our own network we forgot was still running the old version." If you want help auditing where that margin might exist in your own CI/CD estate, email sales@halfteck.com.