Rapid7 Details Critical Flaw in TeamCity That Is Already Being Exploited, CISA Imposes Tight Deadline

CVSS 9.8 vulnerability allows remote code execution without authentication on JetBrains TeamCity servers. CISA added it to the KEV on August 5 with a three-day deadline.
Rapid7 updated its technical analysis of CVE-2026-63077 on Monday, a critical remote code execution vulnerability in JetBrains TeamCity On-Premises, just days after CISA added it to the catalog of actively exploited vulnerabilities. The CVSS score is 9.8 and the vector is among the most dangerous. Any attacker with HTTP or HTTPS access to the server can execute operating system commands with the privileges of the TeamCity process, without needing credentials.
TeamCity is one of the most widely adopted CI/CD platforms by medium and large engineering teams, with tens of thousands of servers exposed to the internet according to public Shodan surveys. A compromised server serves as an ideal pivot. It directly enters the pipeline, accessing secrets, cloud credentials, deployment tokens, and source code. Ransomware groups looking for supply chain compromise often enter through vectors like this.
The Root of the Problem
According to Rapid7 Labs, the vulnerable version of TeamCity constructs an allowlist for XStream to restrict which Java classes may be deserialized when the server processes unauthenticated agent requests. The error is one of omission. The developer added TeamCity protocol classes to the list, but did not remove the default XStream permissions, which already cover a broad surface. The correct patch inserts NoTypePermission.NONE before the allowlist, making the list exclusive. Rapid7 confirmed in testing that the fix resolves the vector.
JetBrains disclosed the flaw on July 27 and released patched builds on the same day: TeamCity 2026.1.3 (build 222742) and TeamCity 2025.11.7 (build 208264). For servers that cannot be updated immediately, the company offers a security patch plugin that covers versions since 2017.1. CISA added the CVE to the KEV on August 5 and imposed a three-day deadline for federal agencies to apply the fix, with the deadline expiring on August 8.
Where Exposure Hurts
In the U.S., federal agencies running TeamCity in contractor environments are under direct pressure from CISA. The audits the agency typically conducts after inclusion in the KEV are known to generate public embarrassment, and defense contractors will have to document remediation on a tight timeline or risk suspension of their authority to operate.
In Europe, the situation is more diluted. JetBrains, headquartered in Prague, has a concentrated installed base in Germany, the Czech Republic, Poland, and the United Kingdom, where banks and telecoms run TeamCity to orchestrate deployment pipelines. No organization has publicly commented on the exposure as of this writing, which is standard for incidents of this nature while response teams continue to investigate. There is also no disclosed evidence of compromise on specific names, only confirmation of active mass exploitation by CISA.
What to Do If You Operate TeamCity
Engineering teams should treat the update as a Sev-1 incident, not as a scheduled maintenance window. The correct order is: upgrade to 2026.1.3 or 2025.11.7, or apply the security patch plugin; rotate all secrets stored in TeamCity, including cloud tokens, SSH keys, registry credentials, and API keys; audit logs for requests to the agent endpoint prior to the patch; and, for servers exposed to the internet, check for signs of persistence such as unusual cron jobs, new containers, and suspicious outbound connections.
In Brazil, global integrators and banks that operate CI pipelines for core banking maintain typical exposure: TeamCity in an internal network, without direct exposure to the internet, but with privileged access to production environments. The risk for these operations lies less in public exposure and more in lateral movement. An attacker already inside the corporate network, by any means, can turn TeamCity into an escalation point at minimal cost, and the chain ultimately ends in production code signed with legitimate credentials.
The Common Bug That the Ecosystem Has Yet to Fix
What CVE-2026-63077 exposes is not the bug itself, which is common in Java deserialization, but how little the DevOps ecosystem has evolved in hardening by default. CI servers continue to be treated as internal tools when in practice they operate as brokers of production credentials. Until this premise changes, the next supply chain compromised through this vector is merely waiting for the next forgotten XStream.