CISA Gives US Agencies Until Today to Patch TeamCity RCE as Exploitation Goes Active
The US cybersecurity agency CISA added a critical JetBrains TeamCity flaw to its Known Exploited Vulnerabilities catalog on August 5, and the patch deadline for federal agencies is today, August 8. Two days later, JetBrains acknowledged that attackers are already exploiting it in the wild.
The vulnerability, tracked as CVE-2026-63077, carries a CVSS score of 9.8 out of 10. It is a deserialization bug in the TeamCity agent polling protocol that lets an unauthenticated attacker with network access to the server run operating system commands with the privileges of the TeamCity server process. No credentials, no user interaction, no prior foothold — just a reachable server. CISA's alert on the catalog addition describes it as a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol.
A bug in the build server is a bug in the supply chain
TeamCity is JetBrains' commercial CI/CD server, the tool many software teams use to compile code, run tests, and ship builds. It is the kind of system that sits quietly at the center of an engineering org, holding source repositories, deployment credentials, and the signing keys that vouch for the software a company releases.
That is exactly why attackers keep coming back to it. Russian state-linked groups and ransomware affiliates have attacked unpatched TeamCity servers for years, and the 2023 wave (CVE-2023-42793, also a 9.8) was tied to North Korean actors compromising developer environments. Help Net Security's advisory notes that state-sponsored groups and ransomware gangs have a documented history of leaning on TeamCity vulnerabilities.
A successful exploit of CVE-2026-63077 does not just break into one server. It can expose stored secrets, alter build configurations, tamper with build artifacts before they ship, and give the attacker whatever network reach the TeamCity service account has. In shops that run the server with broad privileges, that can extend into production deployment infrastructure.
JetBrains spells out the impact in its original advisory: a successful attack can expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines. In practice, that means an attacker who owns the build server can quietly inject code into the next release of every product built on it — the same playbook behind the SolarWinds-style supply chain attacks that defined the early 2020s.
From disclosure to confirmed exploitation in nine days
Security researcher Antoni Tremblay privately reported the bug to JetBrains on July 10. The company shipped fixed versions — 2025.11.7 and 2026.1.3 — and a security patch plugin for older servers on July 29, saying it was not aware of active exploitation at the time.
That changed within days. On August 5, CISA added the bug to its Known Exploited Vulnerabilities catalog, citing evidence of active exploitation, and ordered US Federal Civilian Executive Branch agencies to complete remediation by August 8 under Binding Operational Directive 26-04. Three days is about the shortest window the directive allows; CISA's three-day deadlines signal that it expects attacks to move fast. The Hacker News coverage notes the agency has not confirmed the identity of the threat actors, how the attacks are being carried out, or the scale of the effort.
JetBrains confirmed on August 7 that it had received reports of active exploitation and attempted exploitation against unpatched servers, and published indicators defenders can look for. A log entry containing com.thoughtworks.xstream.converters.ConversionException may indicate an attempted or successful attack; after patching, a com.thoughtworks.xstream.security.ForbiddenClassException message means a later attempt hit the fix and was blocked. Unexpected unauthorized build agents with names starting with scan are also a red flag worth investigating.
The company says it found no sign that TeamCity Cloud environments were compromised, and cloud customers do not need to take action. The problem is on-premises deployments — roughly 4,500 of which were publicly reachable on the internet at the time of discovery, per Censys data cited by ITBriefcase. Nine days separated disclosure from confirmed exploitation, which is faster than the three-to-four-week windows that are common for complex bugs.
What defenders should do
The fix list is short. Upgrade on-premises TeamCity to 2025.11.7 or 2026.1.3, or install the security patch plugin if you cannot upgrade yet. The plugin covers only this one vulnerability, so a full upgrade is still the right end state. Servers running 2017.1 to 2018.1 need a restart after installing the plugin; from 2018.2 onward it can be enabled without one.
If patching will take more than a few hours, pull the server off the internet or restrict access to trusted networks. The flaw only matters when the server is reachable, and removing exposure cuts the attack surface completely. JetBrains goes further, recommending that even the login screen and REST API of internet-facing servers be treated as potential entry points, and that servers run with the minimum operating system privileges required for normal operation.
Do not assume patching closes the book. If your server was internet-accessible between July 29 and the day you patched, treat it as potentially compromised before you apply the fix. Review build logs and audit logs for the indicators above, check for unauthorized agents, and verify the integrity of recently produced build artifacts. If there is any sign of trouble, rotate every credential the server could reach — API tokens, cloud keys, signing certificates, database connection strings.
The secrecy around the attacks does not make them less dangerous. Neither JetBrains nor CISA has named the actors behind the exploitation wave, and the agency's KEV entry for the bug lists the ransomware association as unknown. What defenders do know is the pattern: a critical, unauthenticated flaw in a widely deployed build system gets patched, then gets weaponized within days. That timeline is worth reading closely. Many organizations still run patch cycles on monthly or quarterly cadences, and a bug like this one does not wait for the calendar.
A cheaper path into software supply chains
There is nothing exotic about the way this flaw works. Deserialization bugs have been a staple of Java's security problems for over a decade, and the protocol involved — agent polling — is the channel build agents use to ask the server for work. Because the polling exchange happens before any authentication, the code path sits in the untrusted zone by default. Researchers had flagged TeamCity before, and the 2021 and 2023 incidents showed why: build servers are where credentials accumulate and where tampering does the most covert damage.
A catalog that keeps growing
TeamCity is one entry in a busy month for the KEV catalog. Apache Tomcat, Langflow, and N-able N-central flaws joined the list in an earlier round tied to a Chinese AI hacking campaign that hit more than 460 targets, and the N-able case carried its own warning about incomplete patches. Healthcare breaches have kept 2026 on pace for a record year, with DentaQuest alone reporting 15 million patients affected. Our Cybersecurity coverage has tracked all of them.
There is also a pattern in how these disclosures land. Vendors patch quietly, advisories go out, and organizations triage the alert against everything else on their plate. For most bugs that is a reasonable trade. For a 9.8 in a build server, it is not. The difference between a routine update and a supply-chain incident is often just a matter of hours, and the TeamCity timeline — nine days from disclosure to a confirmed exploitation — shows how little patience attackers have with unpatched infrastructure.
The broader lesson is aimed at the way security teams measure their own risk. An internet-facing CI/CD server is worth more to an attacker than an internet-facing web server, because it holds the keys to every downstream system. Teams that treat build infrastructure as internal-only, trust it implicitly, and expose it for convenience are handing attackers a shortcut that no endpoint protection will catch. Keeping build systems off the public internet, patching them on the same day a critical advisory lands, and planning for the possibility of compromise are cheap habits next to the cost of a poisoned release.
For organizations outside government, the calculus is simple. This one is different pacing: critical unauthenticated RCE, a supply-chain system at the center of the software build process, and a three-day federal deadline. If you run TeamCity, you should assume attackers are probing for it right now. Patch today.