A working exploit is now public for the JetBrains TeamCity flaw that CISA says attackers are already using, together with a detailed account of exactly what went wrong in the code.
Rapid7's Stephen Fewer published the analysis on 7 August, along with a proof of concept script. It covers CVE-2026-63077, an unsafe deserialization flaw rated 9.8 out of 10, which lets anyone able to reach a TeamCity server over HTTP or HTTPS run operating system commands as the TeamCity server process, with no credentials at all.
JetBrains disclosed the issue on 27 July and said at the time it knew of no active exploitation. That changed on 5 August, when CISA added the CVE to its Known Exploited Vulnerabilities catalog, which we covered when CISA confirmed attackers were exploiting it. Rapid7's write-up is the first public explanation of the underlying defect, and it ships with exploit code.
What is affected
TeamCity builds before 2026.1.3 and before 2025.11.7 are vulnerable. Rapid7 compared 2026.1.2 against the patched 2026.1.3 and confirmed the fix stops the exploit it describes.
TeamCity is a build server, which makes this worse than the raw score suggests. Build servers hold source code, signing keys and deployment credentials, and they push artifacts to production. We made the same point when a critical Jenkins flaw broke the barrier between build agents and the server.
How the attack works
TeamCity coordinates builds through a central server that its build agents poll for work. Those agent endpoints, under /app/agents/v1, are largely unauthenticated by design. An attacker first sends a POST to the register endpoint, which hands back a session identifier in a response header. That header is not proof that anyone authenticated; it just identifies a polling connection. The attacker then POSTs arbitrary XML to the error command endpoint, and the server rebuilds Java objects from it.
The root cause is a subtle one. TeamCity maintains an allowlist of Java classes that are safe to rebuild from incoming XML, using the XStream library. The problem is that TeamCity added its own entries without first clearing the permissions XStream installs by default. Those defaults permit whole type families, including Map and Throwable, so an allowlist that was meant to be exclusive was in practice additive. The patch inserts a single call that wipes the permission list before the TeamCity entries are added, making the allowlist deny by default as intended.
Rapid7 walks through the gadget chain that the leftover permissions made possible: a TeamCity exception class accepted under the Throwable permission leads through declared fields to a database connection object, a callback forces that object to open a connection, and the resulting SQL writes a JSP file into the TeamCity webroot. A second HTTP request to that file executes it on the server.
What you should do
Upgrade to TeamCity 2026.1.3 or 2025.11.7. There is no partial mitigation described in the analysis, and with the CVE already in KEV and exploit code now public, the window for patching quietly has closed.
If a TeamCity server was reachable from the internet before it was patched, treat it as potentially compromised rather than simply fixed. Based on the described chain, the most direct thing to check for is unexpected JSP files in the TeamCity webroot, alongside the usual review of build configurations, stored credentials and recently issued tokens. Build servers rarely need to be exposed to the internet, and restricting who can reach the agent endpoints removes the precondition for the attack entirely.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.