Zerodayhub

TL;DR — The TeamCity RCE tracked as CVE-2026-63077 scores 9.8 and needs nothing but network access. Every on-premises version is affected. A build server holds your cloud credentials, signing keys and deploy access, so this is a supply-chain problem wearing a CI/CD costume. Upgrade to 2026.1.3 or 2025.11.7, then rotate every secret it ever held.

What Is the TeamCity RCE in CVE-2026-63077?

JetBrains TeamCity is a continuous integration and delivery server: it compiles your code, runs your tests, and pushes the result to production. To do that it needs credentials for nearly everything — cloud provider keys, private SSH keys, registry tokens, signing material, source repository access. It is, in credential terms, one of the richest boxes on most corporate networks.

The TeamCity RCE lets an unauthenticated attacker who can reach that server over HTTP or HTTPS run operating system commands on it, with whatever privileges the TeamCity process holds. No account. No user interaction. All On-Premises versions are affected — there is no lucky version window here. TeamCity Cloud was patched by JetBrains and, per the vendor, showed no signs of exploitation attempts.

Compromising a build server is not the same as compromising a server. An attacker who owns your CI/CD pipeline can read every secret it stores and quietly alter what it builds. Artefacts that come out the other side are signed, trusted and shipped to your customers.

How the TeamCity RCE Works

TeamCity uses a distributed architecture: a central server hands work to build agents, and those agents constantly poll the server for jobs and report status. So that agents can be onboarded without someone manually approving each one, a set of endpoints under /app/agents/v1/ is deliberately unauthenticated. That design decision is not the bug. What happens to the data arriving there is.

Agent traffic is XML, deserialised using the XStream library. Deserialising attacker-controlled data is famously dangerous, so TeamCity does the right thing in principle and applies an allowlist restricting which Java classes may be reconstructed. Rapid7’s analysis found the flaw: the allowlist adds TeamCity’s own protocol classes without removing XStream’s existing default permissions.

An allowlist that adds to the defaults rather than replacing them is not an allowlist. It is a slightly longer list of things you already allowed.

The practical effect is that a request body handled by the error-parsing path is passed to the deserialiser with far more of the Java class universe reachable than intended. From there it is a textbook gadget chain: reconstruct an object graph whose side effects, when the deserialiser resolves a property, end in a database connection getter. Apache DBCP dutifully opens an in-memory database and runs the initialisation SQL it was configured with — and that SQL writes a web shell to disk.

Nothing in that chain is a memory-safety bug or an exotic primitive. Every link is a library doing exactly what it documents. This is what makes deserialisation vulnerabilities so durable: the attacker supplies a shape, and your own dependencies provide the execution.

Reading the CVSS Score

There is no argument to be had with this vector. Every metric that can be pinned is pinned.

Note I:H alongside C:H. For most 9.8s the integrity metric is a formality. Here it is the headline: an attacker who can alter build output has a route into every system your pipeline deploys to, and into every customer who consumes what you ship. The scope metric says S:U, but a build server that signs artefacts crosses trust boundaries that CVSS has no vocabulary for.

EPSS is worth mentioning only to dismiss it. The vulnerability sits on CISA’s KEV list, which means exploitation is observed, not predicted. A probability score cannot tell you anything more useful than that.

Active Exploitation of the TeamCity RCE

The sequence here is worth reading closely, because it is a clean illustration of how quickly the picture changes. JetBrains published its advisory on 27 July 2026 alongside fixed builds, stating it was not aware of any active exploitation — an accurate statement at the time. Nine days later CISA added the CVE to the KEV catalogue, which it only does on evidence of exploitation in the wild.

Two days after that, Rapid7 published a complete root-cause analysis. Public technical detail of that quality reliably shortens the gap between “someone can do this” and “anyone can do this.” TeamCity servers also have form: state-sponsored groups and ransomware affiliates have gone after unpatched TeamCity instances in previous campaigns, so the attacker interest is well established.

Neither JetBrains nor CISA has published details of who is exploiting it or at what scale. Treat that absence as missing information rather than reassurance. What to hunt for:

• Requests to /app/agents/v1/ endpoints from addresses that are not your build agents
• XML request bodies to agent endpoints containing unexpected Java class names — particularly data-source or collection types that have no business in agent traffic
• New or modified JSP files under the TeamCity web application directory, the clearest sign the chain completed
• Child processes spawned by the TeamCity JVM — shells, interpreters, network utilities
• Outbound connections from the build server to destinations no pipeline legitimately calls
• Use of credentials stored in TeamCity from IP addresses outside your normal ranges

Remediation & Mitigation: Patching TeamCity

Upgrade to TeamCity 2026.1.3 or 2025.11.7. If you are running something older and cannot upgrade immediately, JetBrains provides a security patch plugin covering versions from 2017.1 onwards. TeamCity Cloud customers need do nothing.

Then assume compromise and work through the rest. A build server that was internet-reachable on a vulnerable version between late July and now should be treated as breached until proven otherwise.

• Patch or apply the plugin. Every instance, including the one running in a corner of the office that nobody owns any more.
• Rotate every secret TeamCity held. Cloud keys, SSH keys, registry tokens, signing certificates, database credentials, API tokens. All of them were readable to anyone who landed code execution.
• Audit build artefacts produced during the exposure window. Compare against source, verify checksums, and check for build steps or scripts nobody remembers adding.
• Take it off the public internet. A CI/CD server rarely needs to be internet-facing. Put it behind a VPN and restrict agent traffic to known agent addresses.
• Review agent registrations for build agents you do not recognise.

The structural lesson is about where deserialisation shows up. This is the second time this week we have covered a vulnerability whose final step was a Java object being reconstructed from untrusted input. Any endpoint that must accept unauthenticated data and hand it to a deserialiser deserves a strict, closed allowlist — one that replaces the defaults rather than extending them, and that is tested by trying to deserialise something it should refuse.

The broader one is about how we classify infrastructure. Build servers are usually filed under developer tooling and patched on a developer-tooling schedule. In terms of what an attacker gets for owning one, TeamCity belongs in the same tier as a domain controller.

Related ZeroDayHub Coverage

This is becoming a pattern worth watching: the Tomcat EncryptInterceptor bypass also ended at a Java deserialisation sink once its guard failed open, and the Langflow unauthenticated RCE was another case of a platform’s stored credentials being the real prize rather than the host itself.

Sources & Further Reading

• CISA Known Exploited Vulnerabilities Catalog
• NVD — CVE-2026-63077
• Rapid7 — Root cause analysis of the XStream allowlist flaw
• The Hacker News — CISA flags TeamCity flaw under active exploitation
• Help Net Security — JetBrains advisory and affected versions
• BleepingComputer — Vendor warning and impact
• runZero — Finding affected assets on your network