The Foothold Isn’t the Breach: The Cadence Incident

TL;DR 

• In August 2026, attackers used a known, already-public TeamCity flaw (CVE-2026-63077, CVSS 9.8) to get remote code execution on JetBrains’ Cadence service.  

• From that foothold, the attacker compromised an old backup holding long-lived AWS credentials. JetBrains later confirmed files in its own S3 buckets were accessed (scope still being determined), and that source code synced from developers’ IDEs may have been exposed. 

• Cadence is an AI/ML cloud service wired into the developer’s IDE: exactly the kind of credentialed, cloud-reaching workload every company is now standing up by the dozen. More of them, exploited faster, is where this is heading. 

• You won’t patch every AI workload before every N-day, but you can control is how far a foothold travels using default-deny egress, segmentation, and short-lived credentials, so one compromised box stays one compromised box. 

JetBrains’ Cadence Security Incident

Between August 8 and 24, 2026, someone had access inside JetBrains’ Cadence environment. The door was CVE-2026-63077: a critical TeamCity deserialization flaw that lets an unauthenticated attacker run commands on the server. It was public, it was on CISA’s Known Exploited Vulnerabilities list, and the patch existed. The problem was that one internet-facing server hadn’t taken it yet. To JetBrains’ credit, they disclosed the incident in detail and gave customers a clear rotation checklist, the kind of transparency the rest of us learn from. 

A known, actively exploited RCE on CISA’s KEV list should be closed fast. But patching an entire estate ahead of every advisory is a race that no security team can win. Somewhere, a server always lags by a few days. If one of those days can become a cloud-wide credential rotation, patch speed was never going to be the whole defense. So why did a single unpatched box reach that far?  

Once inside, the attacker compromised a full 2024 backup of the Cadence server: credentials and config, including AWS IAM users and their secrets. JetBrains then confirmed the actor accessed files in S3 buckets within its own AWS accounts (full scope still being determined; it doesn’t yet know whether customer-account buckets were reached), and that source code synced from PyCharm may also have been exposed. It hasn’t said how that storage was reached, but its own indicators (“credentials used from unexpected IP addresses,” “unexpected access to cloud storage”) read like the extracted keys being replayed against the AWS API, not the server reaching out. The remediation shows the potential Blast Radius: rotate everything: AWS, GitHub, GitLab, npm, PyPI, Docker, Slack, SSH keys, signing certs.   

The patch would have prevented the entry. But the reason one entry became a cloud-wide incident sits a layer deeper, in Blast Radius. 

What the Industry Keeps Getting Wrong 

Almost everyone in the industry has inherited certain defaults: 

Standing credentials are stored energy. The keys that turned RCE into a cloud breach were long-lived IAM secrets sitting in a two-year-old backup, still valid. A backup is meant to be a safety net, but static credentials turn it into a loaded one. A leaked secret that’s still good months later has pre-positioned the attacker’s next move for them. 

Reachability is granted by accident. The compromised server sat within reach of a full backup stuffed with live credentials, the one artifact that unlocks the cloud. Nothing about running ML jobs required that, but nothing stopped it either. In most clouds “can reach” is the default and “can’t reach” is what you have to go out of your way to configure. 

With no friction, there’s no time and no signal. The intrusion ran for over two weeks. Because the moves were unobstructed, nothing slowed the attacker and no anomaly was loud enough to force a response. 

Containment goes beyond prevention; it generated the high-fidelity alert in the first place. 

The theme underneath all three: the ceiling on the damage was set by architecture long before the attacker showed up. You patch on the attacker’s schedule, but you design reachability once, on your own, and it holds every day a patch lands late.

Why AI Makes Reachability More Critical 

Cadence is a preview. It lets developers run ML and heavy GPU jobs straight from their IDE: code syncs up, executes on cloud GPUs, results come back. An AI workload that holds cloud credentials, pulls source, and runs arbitrary compute is exactly what enterprises are now deploying everywhere: training jobs, inference services, agent runtimes, coding backends, tool servers. 

Every one is a new credentialed identity with a path into your cloud, and the window to secure each is shrinking, because attackers now weaponize fresh advisories in hours, increasingly with AI doing the recon and pivoting. 

Put those together and the Cadence outcome stops being about Cadence: more AI workloads, each reachable through some future N-day, each holding keys to your cloud. If a compromised workload inherits the reach of everything around it, any one of them is an incident waiting to happen. We can address this by going beyond trying to patch fast enough: instead, assume a workload will be compromised and decide in advance how far it gets to travel. 

What Would Have Happened with Containment Architecture 

This is what Zero Trust means once you apply it to workloads, not just logins: each reaches only what its job needs, on every path, whether or not anything’s been detected. A server that never legitimately reads another account’s S3 simply can’t, so a foothold stays a foothold. 

Three controls would have changed the ceiling on this: 

Retire standing credentials: The whole chain turned on a two-year-old backup’s worth of AWS IAM keys still being valid. Short-lived, role-assumed credentials make a leaked secret close to worthless by the time anyone finds it, and IAM condition keys (source VPC or IP) mean a key lifted from a backup can’t be replayed from the open internet, which is exactly how these appear to have been used. Of the three, this most directly defuses the incident as reported. 

CISO: Draw a firm line against long-lived cloud keys, especially anywhere that gets backed up, and require network or condition scoping on the ones that must remain. 

Engineer: Move to short-lived, role-assumed credentials; scope keys to a source VPC/endpoint; scan backups and artifacts for embedded secrets; rotate often. 

Default-deny egress. Two moves run through the compromised server’s own outbound path: reaching whatever held the backup, and moving data out. Deny-by-default egress with a tight allowlist turns both into a wall and a signal, because a build/ML server connecting to brand-new infrastructure (the exploitation IPs JetBrains published were all external) is not normal. If stolen keys are replayed from the attacker’s own infrastructure, that hop is caught by credential scoping and identity anomaly detection, not this server’s egress. 

CISO: Treat egress control as a first-class containment capability for every cloud and AI workload, not a compliance line item. It’s the cheapest place to stop a foothold from becoming exfiltration. 

Engineer: Default-deny outbound from ML/build/agent workloads; allowlist the registries, APIs, and endpoints they genuinely use; alert on the rest. 

Segmentation and Communication Governance. The Cadence server could reach a full, credential-bearing backup at all. Explicit workload-to-workload policy ensures a compromised host sees only what its job requires, not the backup vault, the credential store, or paths it never uses. It won’t stop valid keys used against the AWS API from the internet, but it shrinks what a foothold can even reach and discover. 

CISO: Make internal and east-west reachability something you measure and shrink. 

Engineer: Keep AI/ML workloads segmented away from backup and credential stores; make every reachable path a deliberate grant. 

No single one is a silver bullet for every hop. Credential reuse is defused by scoping and detection; exfiltration and internal reach by egress and segmentation. Together, they cap the Blast Radius no matter which server misses which patch, and none depends on patching in time because that day comes for everyone. 

What You Catch with Containment 

Containment is also where the signal lives. The catchable moments here map onto JetBrains’ own published indicators: cloud keys suddenly used from unfamiliar IPs, storage access from an identity with no prior history of it, IAM roles or policies changing when no one asked, an outbound connection to infrastructure the workload has never talked to. The dependable, environment-wide catch is at the identity and egress layers: the moment a credential is used where it never should be, or reach turns into an outbound connection.  

Default-deny and short-lived, scoped credentials make those moments rare, which is what makes them worth alerting on. 

Key Takeaways 

Security teams still need to patch fast. But patching an entire estate ahead of every advisory is a race you’ll sometimes lose, and Cadence shows what gets decided on the days you do: how far a single foothold travels. As you deploy credentialed AI workloads faster than you can harden each, some entry will eventually land. The variable you fully control is what happens next. The foothold reached a backup, the backup held live keys, the keys reached the cloud, with nothing in between. Patch to prevent the entry; build the “in between” so that when one gets through, it stays an entry. 

Learn about the five testable properties that define a containment architecture.  

Try a free Workload Attack Path Assessment to find the hidden attack paths in your network.  

References 

Aviatrix, "The Containment Era: Beyond Detection-First Security," 2026, https://aviatrix.ai/why-aviatrix/the-containment-era/ 

Cybersecurity and Infrastructure Security Agency, "Known Exploited Vulnerabilities Catalog," https://www.cisa.gov/known-exploited-vulnerabilities-catalog 

National Institute of Standards and Technology, "Zero Trust Architecture," August 11, 2020, https://csrc.nist.gov/pubs/sp/800/207/final 

The Hacker News, "Attackers Breached JetBrains Cadence via Unpatched TeamCity, Extracting AWS Credentials," September 5, 2026, https://thehackernews.com/2026/09/attackers-breached-jetbrains-cadence.html 

The Hacker News, "CISA Flags TeamCity CVE-2026-63077 RCE Flaw Under Active Exploitation in the Wild," August 6, 2026, https://thehackernews.com/2026/08/cisa-flags-teamcity-cve-2026-63077-rce.html 

The Hacker News, "Critical TeamCity Flaw Could Let Attackers Run OS Commands Without Logging In," July 28, 2026, https://thehackernews.com/2026/07/critical-teamcity-flaw-could-let.html 

The JetBrains Blog, "Security Incident Affecting JetBrains Cadence," August 28, 2026, https://blog.jetbrains.com/pycharm/2026/08/cadence-security-incident-august-2026/