A critical flaw that took months to become urgent
JetBrains patched CVE-2026-63077 in TeamCity On-Premises versions 2025.11.7 and 2026.1.3 on July 25, closing a deserialization flaw in the agent polling protocol that allows unauthenticated remote code execution. The CVSS score of 9.8 reflects about as severe a rating as the scoring system allows, since exploitation requires no credentials and the agent polling protocol is typically reachable by design from build agents communicating with the central server. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 5, roughly two weeks after the patch shipped.
The gap that matters came next. CISA did not confirm active ransomware exploitation of the flaw until September 23, nearly two months after the patch became available. That window, long enough for patched organizations to feel they had handled the issue and unpatched ones to deprioritize it as old news, is exactly when ransomware operators appear to have moved in, a pattern that has repeated across multiple vulnerabilities this year where the gap between patch availability and mass exploitation outlasts most organizations' patience for prioritizing a fix.
JetBrains' own environment was reportedly hit
According to reporting on the incident, JetBrains' own Cadence build environments were breached in early September, with attackers extracting AWS credentials from the compromised infrastructure. A vendor's own build systems being compromised by a flaw in its own product is an uncomfortable but clarifying data point: if the company that wrote the software and issued the patch could not fully insulate its own infrastructure from exploitation of the flaw it just fixed, customers running the same software on their own less specialized security teams should assume they are at equal or greater risk.
The specific theft of AWS credentials from a build environment points directly at the threat model security researchers have been warning about. Build infrastructure functions as a trust anchor with live cloud credentials, access to source code, and often the ability to push artifacts that downstream systems treat as verified and safe, which makes a compromised build server worth far more to an attacker than its modest role in most architecture diagrams would suggest. Treating it as a peripheral development tool rather than a privileged production system is the root misjudgment this incident exposes.
Why build servers are the target of choice
BreachLock CEO Seemant Sehgal described build servers as high-value targets precisely because compromising one lets an attacker inject malicious code into legitimate builds and steal the signing keys that make tampered releases look authentic to every downstream consumer of that software. SafeBreach's Adrian Culley emphasized that unauthenticated remote code execution via the agent polling protocol means attackers need no credentials at all to begin the compromise, removing the credential theft step that most enterprise intrusions still require.
Black Duck's Boris Cipot and Black Hills Information Security's John Strand both pointed to the same underlying dynamic: a compromised build server can expose credentials, alter the server itself, and undermine the integrity of every build artifact it produces going forward, while software supply chain tools broadly offer attackers broad distribution capabilities, since one compromised build pipeline can taint every downstream deployment that trusts its output without re-verification. Strand specifically flagged that attackers are increasingly targeting software supply chain tools for exactly this distribution leverage, a strategic shift away from chasing individual endpoints one at a time.
Why ransomware crews specifically want this access
Ransomware operators exploiting a build server vulnerability might seem like an odd fit, since ransomware's classic playbook targets file shares and backup systems for encryption, not source code repositories. But build servers sit deep inside an organization's internal network with broad access to source control, artifact repositories, cloud credentials, and often direct lines to production deployment systems, making them an efficient beachhead for lateral movement toward the file shares, domain controllers, and backup infrastructure ransomware operators ultimately want to reach.
An unauthenticated, no-credential-required remote code execution flaw is also simply easier to weaponize at scale than vulnerabilities requiring stolen credentials or social engineering, which matters for ransomware affiliates running opportunistic scans against internet-exposed TeamCity instances rather than conducting targeted reconnaissance against a single victim. Scale and ease of exploitation, more than target sophistication, likely explain why this flaw moved from patch to ransomware headline in two months. Affiliates working from a shared playbook can point automated scanners at the entire internet-facing TeamCity population and let the tooling identify which instances remain unpatched, with no manual targeting required.
The CI/CD patching lesson
The practical fix is straightforward: confirm every TeamCity On-Premises instance is running 2025.11.7, 2026.1.3, or later, and if not, patch immediately and treat any instance that was internet-reachable and unpatched during the exposure window as a candidate for compromise review, including rotation of any credentials the build server could access. Organizations should also review whether their TeamCity agent polling protocol needs to be reachable from outside a tightly controlled network segment at all, since reducing exposure surface protects against the next CI/CD vulnerability as much as this one.
More broadly, this incident is another data point in a now-familiar pattern: development and build infrastructure routinely receives lower patching priority than customer-facing production systems, on the reasoning that it is internal and less exposed. CVE-2026-63077 shows that reasoning fails when the tool in question is, by design, built to accept automated connections from build agents, making it exactly as exposed as any internet-facing application and deserving of the same patch SLA enterprises apply to their highest-priority production systems.
