JetBrains spent a month telling every TeamCity customer on the planet to patch a critical remote-code-execution bug. Then it left the same bug open on its own server for at least 16 days, and attackers walked straight into the AWS accounts behind Cadence, the company’s cloud compute service for PyCharm. The result, disclosed on August 28, 2026, is one of the cleanest case studies yet of how a single unpatched CI/CD server can cascade into a full cloud credential exposure, and it lands in the same month venture firms poured $300 million into a cloud-security startup built to catch exactly this kind of failure.
What Happened: The Cadence Breach in Brief
The vulnerability at the center of this story is CVE-2026-63077, an unauthenticated remote-code-execution flaw in TeamCity’s agent polling protocol. JetBrains privately received the report from security researcher Antoni Tremblay on July 10, 2026, and published a public advisory on July 27. CISA added the bug to its Known Exploited Vulnerabilities catalog on August 5, confirming it was already being used in real attacks. JetBrains classified it as a deserialization-of-untrusted-data issue and assigned it a CVSS v3.1 base score of 9.8, one tick below the maximum possible severity rating.
Somewhere in that window, the TeamCity server behind JetBrains’ own Cadence service went unpatched. The company’s incident report says attackers exploited the flaw against Cadence between August 8 and August 24, 2026, a run of roughly 16 days during which they moved from a build server into a 2024 Cadence backup, then into AWS Identity and Access Management credentials, and finally into Amazon S3 buckets tied to JetBrains’ AWS accounts. JetBrains disclosed the breach on August 28, four days after the intrusion window it describes.
Inside CVE-2026-63077: The Flaw JetBrains Didn’t Patch on Itself
TeamCity is JetBrains’ continuous integration and delivery server, used to automate builds, tests, and deployments for software teams. CVE-2026-63077 lives in the agent polling protocol, the channel a TeamCity build agent uses to check in with its server. JetBrains wrote in its update advisory that “CVE-2026-63077 can be exploited without authentication,” and that “an unauthenticated attacker with HTTP(S) access to a vulnerable TeamCity server could exploit the vulnerability via the TeamCity agent polling protocol to execute arbitrary operating system commands with the privileges of the TeamCity server process,” a description published in the company’s own TeamCity security advisory.
The bug hits every on-premises TeamCity release before the fix. JetBrains’ affected-version ranges cover anything earlier than 2025.11.7 on the older branch, and the 2026.1 branch from its initial release through 2026.1.2. Fixes shipped in TeamCity 2025.11.7 and 2026.1.3, and JetBrains also released a standalone security-patch plugin for TeamCity 2017.1 and later, so customers who could not immediately upgrade had a way to mitigate the hole without a full version jump. Independent tracking from Tenable’s CVE database confirms the same CVSS 9.8 score and affected-version breakdown.
What makes the Cadence breach notable isn’t the vulnerability itself, it’s the gap between advice and practice. JetBrains told the world to patch on July 27. Its own Cadence-linked TeamCity server was still exploitable on August 8, nearly two weeks after the public advisory and three days after CISA flagged active exploitation in the wild.
How Attackers Moved From TeamCity to AWS S3
Once inside the Cadence TeamCity server, the intrusion followed a familiar build-server-to-cloud pattern. JetBrains’ incident writeup, published on its official security advisory, confirms the company found “we recently disclosed CVE-2026-63077, a critical vulnerability in TeamCity that can allow an unauthenticated attacker to execute arbitrary commands on a vulnerable server,” and separately that “we have since confirmed the Cadence environment was vulnerable to CVE-2026-63077 and was exploited through this vulnerability.”
From command execution on the server, the attackers reached a 2024 backup of the Cadence environment. That backup held AWS IAM credentials belonging to both JetBrains employees and, in some cases, Cadence customers who had configured the service to reach their own storage. With those credentials in hand, the intruders pivoted into cloud storage. JetBrains confirmed it had “accessed files stored in S3 buckets within JetBrains AWS accounts used by Cadence,” and separately that source code, configuration files, and project metadata tied to the Cadence service were exposed in the process.
The chain is simple to describe and hard to defend against retroactively: one exposed build server led to a stale backup, the backup handed over live cloud keys, and those keys opened object storage. It is the same shape as dozens of other 2026 incidents, just with the vendor’s own name on the compromised system this time.
What Data Was Exposed, and What JetBrains Still Doesn’t Know
JetBrains has been unusually direct about the limits of its own visibility into the breach. The company said threat actors “obtained access that could have allowed them to reach storage containing data associated with current Cadence users, including email addresses, project source code, and credentials,” but has not published a specific count of affected customers, projects, or S3 buckets.
More striking is what JetBrains admits it cannot yet confirm: whether attackers reached storage buckets inside customer-owned AWS accounts, as opposed to JetBrains’ own. Because Cadence could be configured to access buckets that belong to the user rather than JetBrains, any customer who wired those credentials into the service now has to assume their own bucket access could be compromised too. JetBrains has directly warned that “any credentials or secrets stored in Cadence, contained in the compromised backup, or made available to executions on the affected server should be considered compromised and must be revoked or rotated,” pushing the remediation burden onto every team that ever ran a Cadence job.
CVE-2026-63077 at a Glance
| Detail | Data |
|---|---|
| CVE identifier | CVE-2026-63077 |
| CVSS v3.1 base score | 9.8 (Critical) |
| Vulnerability type | Unauthenticated RCE / deserialization of untrusted data |
| Attack vector | TeamCity agent polling protocol, no authentication required |
| Privately reported | July 10, 2026 (researcher Antoni Tremblay) |
| Public disclosure | July 27, 2026 |
| Added to CISA KEV catalog | August 5, 2026 |
| Affected versions | TeamCity On-Premises before 2025.11.7; 2026.1 through 2026.1.2 |
| Patched versions | 2025.11.7, 2026.1.3 (plus security patch plugin for 2017.1+) |
| Cadence exploitation window | August 8 to August 24, 2026 (approx. 16 days) |
| Cadence breach disclosed | August 28, 2026 |
JetBrains’ Response and Mitigation Guidance
JetBrains has taken the affected Cadence server offline and asked customers to treat any secret ever passed through the service as burned. That includes AWS access keys, session tokens, API keys for third-party services, and any SSH credentials that might have been synced through a Cadence-linked project. The company’s initial advisory, published before the Cadence incident came to light, had already told the wider TeamCity user base that at the time of publishing, it was “not aware of any active exploitation of this vulnerability,” a line that reads differently once you know the company’s own infrastructure was compromised roughly two weeks later.
For TeamCity administrators outside the Cadence incident, the practical guidance hasn’t changed since July: upgrade to 2025.11.7 or 2026.1.3, or apply the security patch plugin if an immediate upgrade isn’t feasible. Given that CISA confirmed active in-the-wild exploitation independent of the JetBrains breach, any organization still running an unpatched on-premises TeamCity server in September 2026 should assume it has already been targeted, not just that it is theoretically exposed.
Rotate First, Investigate Second
Security teams responding to Cadence exposure are being told to rotate credentials before they finish scoping the blast radius, because the cost of a missed key is higher than the cost of an unnecessary rotation. The command below is a starting point for auditing which IAM users have been active recently in an AWS account that may have touched a Cadence-linked pipeline.
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > credential-report.csv
aws iam list-access-keys --user-name <cadence-linked-user>
aws iam update-access-key --access-key-id <KEY_ID> --status Inactive --user-name <cadence-linked-user>Deactivating first and deleting later gives incident responders a rollback path if a key turns out to be tied to a production workload that wasn’t documented anywhere.
Historical Context: 2026’s Year of CI/CD-to-Cloud Breaches
The Cadence breach isn’t an isolated event, it’s the latest entry in a pattern that has defined cloud security through 2026. In April, a threat actor group tracked as TeamPCP used stolen Checkmarx publisher credentials to push malicious images into the official checkmarx/kics repository on Docker Hub, rewriting five existing tags and adding two more before Docker’s monitoring caught the intrusion in about 30 minutes, according to Docker’s own incident writeup. A month earlier, the same campaign family had compromised Aqua Security’s CI/CD pipeline and backdoored the widely used Trivy vulnerability scanner, tracked as CVE-2026-33634, with exposure windows on individual components ranging from roughly three to twelve hours.
Then in August, a self-propagating npm worm named ChainDrop compromised 444 packages and 2,212 versions in under four hours, according to research shared by Eon’s security team. The affected packages included keyv, which alone sees roughly 600 million monthly downloads, meaning the worm’s blast radius touched an estimated 2 billion weekly installations. Its payload harvested npm tokens, GitHub personal access tokens, AWS IAM credentials across 16 regions, GCP and Azure service accounts, Kubernetes configs, SSH keys, HashiCorp Vault tokens, and Docker Hub and Helm credentials, essentially every category of non-human identity a modern build pipeline touches.
What distinguishes Cadence from those incidents is the identity of the victim. Docker Hub, npm, and Aqua Security are infrastructure providers whose compromised trust gets inherited by thousands of downstream users. JetBrains is a vendor that spent its own July advisory instructing customers on exactly how to avoid this outcome, then missed the deadline on its own production system.
2026 CI/CD Supply Chain Incidents Compared
| Incident | Date | Vector | Scale / Exposure |
|---|---|---|---|
| Trivy / Aqua Security compromise | March 19-23, 2026 | Stolen CI/CD credentials, backdoored scanner | Exposure windows of 3-12 hours per component; CI/CD secrets, cloud credentials, SSH keys |
| Docker Hub / Checkmarx KICS | April 22, 2026 | Stolen publisher credentials on Docker Hub | 7 tags rewritten (5 overwritten, 2 added); caught in about 30 minutes |
| ChainDrop npm worm | August 4, 2026 | Compromised GitHub maintainer account, self-propagating | 444 packages, 2,212 versions, ~2B weekly installs exposed |
| JetBrains Cadence breach | August 8-24, 2026 (disclosed Aug. 28) | Unpatched TeamCity RCE (CVE-2026-63077) on vendor’s own server | AWS IAM credentials and S3 buckets in JetBrains accounts; scope of customer bucket access undetermined |
Market Impact: Cloud Security Funding Keeps Climbing
The Cadence disclosure landed in the same week that cloud-security startup Upwind closed a $300 million Series C round, co-led by Bessemer Venture Partners and TCV, at a $3.8 billion valuation, according to reporting from TechFlier. That valuation is roughly triple where the company stood at the start of 2026, when it was valued closer to $1.8 billion after a $250 million Series B. Salesforce Ventures, Greylock, and Craft Ventures joined the round alongside the two lead investors.
The timing isn’t a coincidence so much as a reflection of where buyer attention has shifted. A Q2 2026 cloud security review from IANS noted that the sector’s defining incidents have “continued to cluster around developer platforms, OAuth integrations, CI/CD secrets, cloud credentials and third-party SaaS relationships,” and argued that security teams need continuous visibility into CI/CD identities rather than periodic posture checks. Investors betting nine figures on platforms built to monitor exactly those identities suggests the market has already priced in more incidents like Cadence, not fewer.
For JetBrains specifically, the reputational cost is harder to quantify than a funding round, but it’s real. TeamCity competes directly with GitHub Actions, GitLab CI, CircleCI, and Jenkins for enterprise CI/CD budgets, and “the vendor that tells you to patch didn’t patch itself” is exactly the kind of story that shows up in competitive sales conversations for the next several quarters.
Why CI/CD Pipelines Became Cloud Security’s Weak Link
CI/CD servers occupy an unusual position in the modern cloud stack. They need broad access to build, test, and deploy code across environments, which means they typically hold API keys, cloud IAM credentials, container registry logins, and source code all in one place. A compromise of the CI/CD layer doesn’t just expose one application, it exposes the keys to everything that application depends on.
That concentration of access used to be balanced by the assumption that CI/CD servers sat behind a perimeter, reachable only by internal engineers. TeamCity’s agent polling protocol flaw breaks that assumption entirely, since it required no authentication and only network access to the server. Combined with the industry’s growing reliance on ephemeral backups and cached credentials for convenience, a single RCE in a build server can now reach further into a cloud account than a compromised production database credential would.
The Backup Problem
The Cadence breach is also a reminder that backups are rarely audited with the same rigor as live systems. The compromised backup dated to 2024, meaning credentials that may have already been rotated on production systems were still valid, or at least present, inside an archive that nobody was actively monitoring. Any organization running its own CI/CD infrastructure should treat backup files as a live attack surface, not a cold, low-priority artifact.
What This Means for AWS, Azure, and GCP Customers
The Cadence incident is technically an AWS story, since JetBrains’ compromised infrastructure ran on Amazon S3 and IAM, but the underlying lesson is cloud-agnostic. Any CI/CD tool that stores long-lived credentials for AWS, Azure, or Google Cloud creates the same risk profile: a build server compromise becomes a cloud account compromise the moment those credentials are usable outside the pipeline that created them.
Cloud providers have been pushing customers toward short-lived, workload-identity-based credentials specifically to reduce this exposure. AWS’s IAM Roles Anywhere and OIDC-based role assumption, Azure’s workload identity federation, and Google Cloud’s workload identity pools all let a CI/CD runner assume a cloud role for the duration of a job without ever storing a static access key. The Cadence breach is a strong argument for treating that migration as urgent rather than optional, since static IAM credentials sitting in a backup are precisely what turned a TeamCity RCE into an S3 exposure.
Predictions: Where CI/CD Cloud Security Goes From Here
- Expect more vendors to disclose “we didn’t patch our own product” incidents through the rest of 2026, as CISA’s KEV catalog keeps growing faster than internal patch cycles at software companies themselves.
- Short-lived, workload-identity credentials will move from a best practice to a default requirement in enterprise cloud security audits, specifically because static IAM keys are the common thread across Cadence, ChainDrop, and the Trivy compromise.
- Cloud security funding rounds on the scale of Upwind’s $300 million raise will keep appearing through the rest of the year, as investors bet on platforms that give continuous visibility into CI/CD and non-human identities rather than periodic scans.
- Backup and archive scanning will get more attention from security teams, since the Cadence breach shows a 2024 backup can carry live risk into 2026 if credentials inside it were never rotated.
- Competing CI/CD vendors will use the Cadence breach in sales pitches against TeamCity through at least the next two quarters, pushing JetBrains to publish more detailed hardening guidance than it has so far.
How to Check Your Own TeamCity Exposure
Any team running TeamCity on-premises should confirm its version immediately rather than assuming a prior patch cycle covered this specific flaw, since the affected range spans two separate branches.
# Check installed TeamCity version from the server API
curl -s https://<your-teamcity-host>/app/rest/server | grep -i version
# Versions requiring an upgrade or patch plugin:
# before 2025.11.7
# 2026.1 through 2026.1.2 (inclusive)
# Safe versions: 2025.11.7, 2026.1.3, or earlier releases with the
# JetBrains security patch plugin applied (TeamCity 2017.1+)If the server returns a version inside the affected range, treat every credential the server has ever touched, cloud keys, deployment tokens, source repository access, as compromised until proven otherwise, and rotate before completing a full forensic review.
The Bigger Picture for Cloud and Container Security
Taken together with the Trivy compromise, the Docker Hub KICS incident, and the ChainDrop worm, the Cadence breach confirms that 2026’s dominant cloud security story isn’t misconfigured storage buckets or weak passwords, it’s the software supply chain that builds and deploys everything else. Every one of these incidents traces back to a CI/CD component with more access than its threat model assumed, whether that component was a package registry, a container scanner, or a vendor’s own build server.
For CISOs and platform engineering teams, the practical takeaway is that vendor trust doesn’t substitute for architecture. JetBrains is a well-resourced company that publishes its own vulnerability advisories and still missed its own deadline. Treating any single vendor’s CI/CD tool as inherently safe, regardless of reputation, is the assumption this incident is designed to break.
Frequently Asked Questions
What is CVE-2026-63077?
CVE-2026-63077 is a critical, unauthenticated remote-code-execution vulnerability in JetBrains TeamCity, scored 9.8 on the CVSS v3.1 scale. It allows an attacker with network access to a vulnerable TeamCity server to execute arbitrary commands via the agent polling protocol, without needing valid credentials.
Which TeamCity versions are affected?
All TeamCity On-Premises releases before version 2025.11.7 are affected, along with the 2026.1 branch from its initial release through 2026.1.2. JetBrains fixed the issue in 2025.11.7 and 2026.1.3, and also released a standalone security patch plugin for TeamCity 2017.1 and later.
What happened in the JetBrains Cadence breach?
Attackers exploited CVE-2026-63077 against the TeamCity server behind JetBrains’ Cadence cloud compute service between roughly August 8 and August 24, 2026. From there they reached a 2024 Cadence backup containing AWS IAM credentials, then used those credentials to access files in S3 buckets within JetBrains’ AWS accounts. JetBrains disclosed the incident on August 28, 2026.
Was customer data exposed in the Cadence breach?
JetBrains confirmed that email addresses, project source code, and credentials tied to current Cadence users could have been reached, but has not published an exact count of affected customers or projects. The company also says it has not yet determined whether attackers accessed storage buckets inside customer-owned AWS accounts, as opposed to JetBrains’ own.
What should TeamCity and Cadence users do now?
Upgrade on-premises TeamCity servers to 2025.11.7 or 2026.1.3, or apply the security patch plugin if an immediate upgrade isn’t possible. Anyone who used Cadence should treat all credentials and secrets ever passed through the service, including AWS keys, as compromised and rotate them immediately rather than waiting for JetBrains to finish scoping the breach.
How does the Cadence breach compare to the ChainDrop npm worm?
Both incidents trace back to CI/CD infrastructure and both resulted in cloud credential theft, but ChainDrop was a self-propagating worm that compromised 444 npm packages in under four hours and touched an estimated 2 billion weekly installations, while Cadence was a targeted exploitation of a single unpatched vendor server over roughly 16 days. ChainDrop’s blast radius was broader, while Cadence’s exposure ran deeper within one vendor’s own infrastructure.
Is CVE-2026-63077 being actively exploited?
Yes. CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog on August 5, 2026, confirming in-the-wild exploitation independent of the Cadence incident. Any organization running an unpatched, internet-reachable TeamCity server should assume it has already been targeted.
Why did cloud security funding increase around the same time as the breach?
Cloud-security startup Upwind closed a $300 million Series C at a $3.8 billion valuation in early September 2026, roughly tripling its valuation from the start of the year. The round reflects broader investor confidence that CI/CD identity monitoring and cloud credential visibility, the exact gap the Cadence breach exposed, will remain a growth area for security spending through the rest of 2026.
