XHack
Author
Table of Contents
13
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: CVE-2026-63077 is a CVSS 9.8 unauthenticated remote code execution vulnerability in JetBrains TeamCity On-Premises, caused by unsafe deserialization in the agent polling protocol, an endpoint meant for build agents, not random internet traffic. JetBrains patched it responsibly on July 27, 2026, but CISA added it to the Known Exploited Vulnerabilities catalog just nine days later, on August 5, with a three-day federal patch deadline.
A single crafted HTTP POST request is enough to get code execution as the TeamCity server process, which matters more than most RCEs because TeamCity sits at the center of software build pipelines, holding deployment credentials, source access, and the ability to poison every artifact it ships downstream. If you run TeamCity On-Premises before 2025.11.7 or 2026.1.3, patch now and assume your build pipeline was the target, not just the server.
Most RCE bugs compromise a machine. This one compromises everything that machine builds.
That’s the distinction that gets lost when CVE-2026-63077 gets filed next to every other “critical unauthenticated RCE” alert this month. TeamCity isn’t a web app or a file server. It’s a CI/CD orchestrator that pulls source code, injects secrets, runs build scripts with real privileges, and pushes the output to production. An attacker who pops a TeamCity server doesn’t just get a foothold, they get a seat inside the pipeline that manufactures your software.
The flaw lives in TeamCity’s agent polling protocol, the channel build agents use to check in with the server without a human logging in first. JetBrains’ advisory classifies it as CWE-502, deserialization of untrusted data, and it’s rated CVSS 9.8, unauthenticated, network-exploitable, full impact on confidentiality, integrity, and availability.
TeamCity uses XStream to deserialize Java objects sent to that endpoint. Rapid7’s technical writeup traces the root cause to a broken allowlist: a vulnerable server adds TeamCity’s own protocol classes to XStream’s permitted-type list, but never strips XStream’s own default permissions first. Translation: the allowlist that was supposed to restrict what could be deserialized was additive, not exclusive, so XStream’s factory-default gadget classes stayed reachable too.
An attacker doesn’t need credentials, just HTTP(S) access to the server. They send one POST request carrying a crafted serialized Java object to the agent polling endpoint, which the server accepts because it never verifies the sender is an actual registered build agent. The gadget chain inside that payload writes a polyglot SQL/JSP file to disk, and a follow-up GET request to that file triggers execution. Two requests, no login, arbitrary commands as the TeamCity server process.
Here’s the thing nobody’s headline captures: a compromised web server gets you that server. A compromised TeamCity server gets you the thing that server builds.
TeamCity instances typically hold source code checkouts, deployment credentials (cloud API keys, container registry tokens, signing keys), and the ability to modify build configurations that run on every commit. An attacker with RCE on the server doesn’t need to touch production directly, they just quietly modify a build step, and your own CI/CD pipeline does the deploying for them. That’s the same attack shape behind real software supply chain incidents, where the CI/CD system itself was the actual target, not just the application it built.
That’s also why CISA didn’t wait around. Federal agencies got a three-day patch window instead of the usual few weeks, a signal that this sits in the same severity tier as the internet-facing edge-appliance bugs we’ve covered before, except this one sits deeper in the software lifecycle than a VPN gateway does.
Nine days from a responsible, coordinated patch to confirmed real-world exploitation. That’s the current baseline speed at which attackers reverse-engineer a diff and weaponize it once the patch itself tells them exactly what was broken.
This hits TeamCity On-Premises only. TeamCity Cloud customers are not affected. If you’re running an on-prem TeamCity server on any version before 2025.11.7 or 2026.1.3 with the agent polling endpoint reachable over HTTP(S), you’re in the affected population, and attackers find these the same way they find any internet-facing service: scanning Shodan and Censys for the exposed endpoint, no targeting required.
Watch for the indicators researchers are actually seeing: unexpected child processes spawned by the TeamCity server (shells, script interpreters, download utilities), outbound connections to unfamiliar destinations right after inbound polling traffic, new build configurations or plugins nobody on the team added, and service accounts that showed up on their own.
So yeah, brand note: most vulnerability scans treat a build server like any other box on the network, check the version, flag the CVE, move on. That misses the actual risk, which is what an attacker does with the access once they’re in, not just whether the box is patched.
The XHack AI agent maps what a compromised host can actually reach, credentials, adjacent systems, build configurations, before an attacker gets the chance to. For infrastructure that sits this deep in your software supply chain, human-led VAPT catches the blast radius a version scanner never will, and XHack doesn’t store your findings on our servers either, which matters when the finding is “your build server was talking to an unfamiliar IP.”
CVE-2026-63077 is a CVSS 9.8 unauthenticated remote code execution vulnerability in JetBrains TeamCity On-Premises, caused by unsafe XStream deserialization in the agent polling protocol. An attacker with no credentials can send a single crafted HTTP request to execute arbitrary commands with the privileges of the TeamCity server process.
No. This vulnerability affects TeamCity On-Premises only. TeamCity Cloud customers do not need to take any action for CVE-2026-63077.
Check for unexpected child processes spawned by the TeamCity server process (shells, scripting interpreters, download utilities), outbound connections to unfamiliar hosts shortly after inbound agent polling traffic, unauthorized build configurations or plugins, and new service accounts you don’t recognize. Any of these warrants a full incident response, not just a patch.
Because a build server holds the keys to everything it produces: source code, deployment credentials, signing keys, and the automated pipeline that pushes code to production. Compromising it lets an attacker modify what gets built and shipped, turning your own CI/CD system into the delivery mechanism for their access, the same failure pattern behind major software supply chain incidents.
Restrict network access to the agent polling endpoint so only your actual build agents can reach it, not the open internet. That single network control closes the exploitation path even before you complete the version upgrade, though it should not replace patching, only buy you time to do it safely.
CVE-2026-63077 went from a responsibly disclosed patch to confirmed active exploitation in nine days, and CISA’s three-day federal deadline reflects just how much damage an unauthenticated RCE on a CI/CD server can do compared to a normal web app bug. If TeamCity On-Premises sits anywhere in your build pipeline, patch it today, lock down the agent polling endpoint regardless, and check your logs for the indicators above. A build server breach doesn’t stay contained to the server, it travels with everything that server ships.
Related articles
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member) Read this in 30 seconds: SonicWall confirmed activ...
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member) Read this in 30 seconds: PaperCut RCE vulnerabilit...
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member) Read this in 30 seconds: CVE-2026-8452 is a [&hell...
