CVE-2026-63077: A Critical TeamCity Flaw Is Now Under Active Attack

An Unauthenticated Path to Full Server Control

JetBrains privately received the vulnerability report on July 10, 2026 and published a public advisory 17 days later, on July 27. The company’s own description is stark: the flaw “enables an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and execute arbitrary operating system commands” with the privileges of the TeamCity server process itself — no login, no credentials, no social engineering required, just network access to the server.

The technical root cause, detailed in Rapid7’s analysis published August 7, 2026, is a deserialization flaw in TeamCity’s agent polling protocol: an improperly configured XStream allowlist failed to strip default deserialization permissions before adding TeamCity-specific protocol classes, leaving a path for an attacker to submit malicious serialized data that the server would execute. Rapid7’s proof-of-concept demonstrated the exploit by writing a malicious .JSPWS file — a customized JavaServer Pages extension — to disk, executing an arbitrary command through it, then deleting the file to cover its tracks.

From Disclosure to Confirmed Exploitation in 9 Days

The exploitation timeline moved fast. JetBrains’ own follow-up advisory noted that no active exploitation had been observed at the time of the initial July 27 disclosure — but that changed quickly, and CISA formally added CVE-2026-63077 to its Known Exploited Vulnerabilities (KEV) catalog on August 5, 2026, confirming exploitation in the wild just nine days after the public disclosure. That addition triggered a mandatory response clock for the US federal government: under Binding Operational Directive 26-04, Federal Civilian Executive Branch agencies were required to apply patches or mitigations by August 8, 2026 — a three-day window that reflects how seriously CISA treats an unauthenticated RCE with confirmed real-world exploitation against build infrastructure.

The vulnerability affects all on-premises TeamCity installations; TeamCity Cloud customers are not affected, since JetBrains manages patching directly for the hosted service. Fixed versions are TeamCity 2025.11.7 and TeamCity 2026.1.3, with JetBrains also making a security patch plugin available for older installations running version 2017.1 and above — an unusually broad backport that signals how many legacy TeamCity deployments the company expected to still be in active use.

Why a CI/CD Server Compromise Is Worse Than a Typical Breach

TeamCity sits in a structurally dangerous position in the software supply chain: it’s the system that builds, signs, and deploys code for every project connected to it. JetBrains’ own risk assessment for this CVE lists the consequences of compromise as exposing data and credentials stored on the server, modifying server state, and compromising the integrity of build artifacts — the last point is what separates a CI/CD breach from an ordinary server compromise. An attacker with build-server access can potentially inject malicious code into software that then gets built, signed, and shipped to every downstream customer of the affected organization, turning a single server compromise into a supply-chain attack against everyone who trusts that software.

This isn’t a theoretical concern for TeamCity specifically. State-sponsored hacking groups and ransomware affiliates have previously targeted unpatched TeamCity On-Premises servers, and the credentials typically stored in a CI/CD system — source code repository tokens, cloud deployment keys, artifact registry credentials — make a compromised build server one of the highest-value single footholds an attacker can obtain inside a software organization’s infrastructure.

What This Means for Engineering and Security Teams

1. Patch TeamCity now — this is not a “schedule it for next sprint” vulnerability

With CISA confirming active exploitation and a nine-day gap between disclosure and confirmed real-world attacks, any organization running an on-premises TeamCity instance below 2025.11.7 or 2026.1.3 should treat this as an emergency patch, not routine maintenance. If immediate patching isn’t possible, apply JetBrains’ security patch plugin as an interim mitigation.

2. Rotate every credential the TeamCity server had access to, even after patching

Because the vulnerability allows arbitrary command execution with server-process privileges, patching closes the entry point but does not undo any access an attacker may have already gained. Any organization that ran an unpatched, internet-reachable TeamCity server between July 10 and their patch date should rotate source control tokens, cloud deployment credentials, and artifact-signing keys stored on or accessible from that server as a precaution.

3. Audit build artifacts produced during the exposure window for signs of tampering

Given that build artifact integrity is explicitly named as an at-risk asset, organizations should review builds produced between the vulnerability’s disclosure window and patch deployment for unexpected changes, unauthorized commits reflected in build logs, or artifacts that don’t match expected source-to-build provenance — treating this as a potential supply-chain integrity incident, not just an infrastructure patching gap.

The Pattern Behind CI/CD-Targeted Vulnerabilities

CVE-2026-63077 fits a recognizable and increasingly common pattern: critical infrastructure that sits deep inside the software delivery pipeline — build servers, artifact registries, deployment orchestrators — has become a preferred target precisely because compromising one server can compromise everything that server touches downstream. Security teams that traditionally focused hardening efforts on customer-facing production systems are increasingly finding that CI/CD infrastructure needs the same, or greater, scrutiny, since a compromised build pipeline can poison software before it ever reaches production monitoring.

The nine-day gap between JetBrains’ public disclosure and confirmed active exploitation is also a reminder that publishing a patch does not neutralize a vulnerability — it starts a race between defenders applying the fix and attackers reverse-engineering the patch to build a working exploit. For internet-facing infrastructure with this level of blast radius, that race needs to be won in days, not the weeks or months many patch-management cycles still assume.

Frequently Asked Questions

Sources & Further Reading

• Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077) — The JetBrains Blog
• CISA Flags TeamCity CVE-2026-63077 RCE Flaw Under Active Exploitation in the Wild — The Hacker News
• Rapid7 Analysis of CVE-2026-63077, an unauthenticated Remote Code Execution vulnerability in JetBrains TeamCity — Rapid7
• JetBrains fixes critical unauthenticated RCE in TeamCity On-Premises (CVE-2026-63077) — Help Net Security