The bug is one missing line. TeamCity's agent polling protocol deserializes data with XStream, and the code that set up XStream's allowlist added the TeamCity protocol classes without first clearing the defaults XStream ships with. An allowlist that only ever adds is not an allowlist. It is a union, and the union stayed wide enough to deserialize gadget classes an attacker controls.

That is CVE-2026-63077, rated CVSS 9.8, and it gives an unauthenticated attacker remote code execution with the privileges of the TeamCity server process. CISA added it to the Known Exploited Vulnerabilities catalog on August 5 and set a federal patching deadline of August 8 under BOD 26-04. If you run TeamCity on-premise and have not patched, assume the window to do it quietly has closed.

RelatedSharePoint RCE Flaw Lands on CISA's Exploited List

The XStream allowlist before and after the TeamCity patch Before the patch, XStream's broad default permissions are combined with TeamCity protocol classes, producing a permissive union that allows unauthenticated remote code execution. After the patch, NoTypePermission.NONE denies everything first, so adding TeamCity protocol classes produces a genuinely exclusive allowlist. XSTREAM ALLOWLIST, BEFORE AND AFTER Before the patch After the patch XStream default permissions broad, reaches gadget classes NoTypePermission.NONE deny everything first + TeamCity protocol classes + TeamCity protocol classes Permissive union unauthenticated RCE, CVSS 9.8 Exclusive allowlist only the listed classes load The code was additive where it needed to be exclusive. genztech.blog
Fig 1 Rapid7's Stephen Fewer traced the flaw to an allowlist that "incorrectly adds TeamCity protocol classes without removing XStream's existing default permissions." The fix inserts a deny-all before the list.

How does the exploit actually run?

The entry point is the agent polling protocol, which is the channel build agents use to talk to the server. It accepts serialized objects, and it accepts them before any authentication check has meaningfully constrained who is talking. Feed it a serialized object graph whose classes XStream is still willing to instantiate, and the deserializer does the work for you.

The published proof of concept writes files with a .JSPWS extension, uses them to execute operating system commands, then deletes them from disk. That last step is the part defenders should sit with. The artifact that would have shown up in a file integrity scan removes itself. If your detection strategy for this depends on finding a web shell sitting on the filesystem afterward, it will find nothing while the box is fully owned.

Why a build server is the worst place to lose

Rating this as "a CI server got popped" undersells it. A TeamCity server holds the credentials that let builds do their jobs: source control tokens, artifact registry keys, cloud deployment credentials, and frequently code signing material. It also has write access to the artifacts your production systems will pull and run without further inspection.

An attacker with code execution on that host does not need to touch production directly. They can wait for the next build and let your own deployment pipeline carry the payload across the trust boundary, signed with your key, from a source your infrastructure already trusts. That is why supply chain intrusions keep starting at exactly this kind of box, and why the federal deadline was three days rather than three weeks.

  1. Aug 5, 2026CISA adds CVE-2026-63077 to the KEV catalog confirms exploitation in the wild
  2. Aug 7, 2026Rapid7 publishes root cause analysis identifies the XStream allowlist mistake
  3. Aug 8, 2026Federal patching deadline under BOD 26-04 three days from listing to deadline
  4. NowAssume compromise on unpatched internet-facing servers patching alone does not evict an attacker

Who is exploiting it, and how widely?

Unknown, on both counts. Neither CISA nor Rapid7 has attributed the activity, and the scale of exploitation has not been quantified publicly. That absence is worth stating plainly rather than filling with speculation, but it should not be read as reassurance. KEV listing requires evidence of real-world exploitation, so the question is not whether this is being used. It is how many operators are using it and against whom.

RelatedCisco FMC Hardcoded Credentials Exploited: Patch Due Today

What to do today

Patch to the fixed on-premise build first, then treat any internet-exposed server that was unpatched after August 5 as potentially compromised. Patching closes the door; it does not remove anyone already inside. Rotate every credential the TeamCity server could reach, including source control tokens, registry keys, cloud roles and signing keys, because credential theft is the obvious first move for anyone who got in. Review recent build artifacts and pipeline definitions for modifications you did not authorize.

Then fix the exposure that made this reachable. A build server does not need to accept agent connections from the open internet. Putting the agent protocol behind a VPN or an allowlisted network path would have turned a critical unauthenticated RCE into an internal-only problem, and it will do the same for the next deserialization bug, which there will be.

What to watch · next 90 days
  • Attribution. If a known access broker is behind the scanning, expect ransomware deployment to follow on a lag of weeks, not days.
  • Downstream artifact tampering. The real damage from CI compromise shows up later, in a build nobody thought to re-inspect.
  • More XStream allowlists. This mistake is a pattern, not a one-off. Any product that configures XStream permissions additively has the same latent bug.
  • Exposure counts. Nobody has published how many on-premise TeamCity servers face the internet. That number, when it lands, sets the real scale of this.
Primary sources

Original analysis by GenZTech. Exploitation status and root cause reporting via The Hacker News and CISA's KEV catalog.