CVE-2026-63077: TeamCity's Unauthenticated RCE Just Landed on CISA's KEV List

If you run TeamCity On-Premises and haven’t patched since late July, stop reading and go check your version number. CVE-2026-63077 lets anyone who can reach your build server over HTTP run commands as the TeamCity process, no login required, and CISA confirmed on August 5 that it’s being actively exploited.

What the bug actually is

TeamCity’s agent polling protocol is how build agents check in with the server: register, ask for work, report status. That channel uses XStream to deserialize the data agents send. To stop an attacker from abusing that deserialization, TeamCity is supposed to enforce an allowlist that restricts which Java classes the server will actually instantiate from incoming data.

The allowlist was built wrong. Instead of replacing XStream’s default permissions with a tight, TeamCity-specific list, the fix added TeamCity’s protocol classes on top of the defaults and left the defaults in place. XStream’s stock permissions include a known gadget chain, a sequence of otherwise-innocuous classes that, chained together during deserialization, let an attacker execute arbitrary code. That gadget chain was still reachable through the agent polling endpoint, and that endpoint doesn’t require authentication, because agents haven’t registered yet when they first poll.

Put together: an attacker with network access to the server sends a crafted payload to an endpoint that exists specifically to serve unauthenticated agents, and gets command execution with the privileges of the TeamCity server process. CVSS 9.8. No login, no user interaction, no social engineering.

Why this one is worse than the average CI/CD bug

A compromised build server isn’t just a compromised server. TeamCity typically holds source code access, deployment credentials, signing keys, and artifact repository tokens, and it sits in the path between “developer pushes code” and “code runs in production.” An attacker with server-process privileges can read those secrets, tamper with build artifacts before they’re signed, or inject malicious steps into pipelines that look identical to legitimate ones in the TeamCity UI.

That’s the same class of risk we walked through with the Langflow unauthenticated RCE chain a few weeks ago: the tools that sit closest to your deploy pipeline are the highest-value targets precisely because compromising them compromises everything downstream. This is a different vendor and a different bug class, but the blast radius reasoning is identical. If your CI server is public-facing, or reachable from a network segment broader than “engineers who need it,” this jumps the queue ahead of whatever else is in your patch backlog this week.

Worth separating from JetBrains’s other recent CVEs, too. The Hub and YouTrack bugs we covered in July were account-takeover and privilege-escalation flaws in different products entirely. This is a distinct vulnerability, in TeamCity specifically, in a different component (the agent protocol, not authentication), and it’s the one currently on CISA’s KEV list.

Who’s affected

TeamCity On-Premises, versions before 2025.11.7 and before 2026.1.3. TeamCity Cloud is not affected, according to JetBrains. If you’re not sure which deployment model you’re running, check with your infrastructure team before assuming you’re in the clear.

The practical exposure question is simpler than the CVE description makes it sound: can an unauthenticated request reach your TeamCity server’s agent polling endpoint from outside your trust boundary? If the server is internet-facing at all, or reachable from any network segment you wouldn’t call fully trusted, you’re exposed regardless of how your internal auth is configured, because this bug lives before authentication happens.

How to patch it

Two paths, depending on where you are:

On 2025.x or 2026.x already. Upgrade to 2025.11.7 or 2026.1.3. Both releases have been verified to close the deserialization path.

On an older supported release (2017.1 and up). JetBrains published a security patch plugin that closes the hole without requiring a full version upgrade first. Install that immediately, then plan the version upgrade on your normal schedule rather than treating them as one blocking task.

Either way, don’t stop at the version bump. If your server was internet-facing before you patched, treat it as a potential compromise until you’ve checked logs: unexpected process spawns, outbound connections the build process wouldn’t normally make, and any pipeline steps that don’t match your source-controlled build configuration. Rotate credentials the TeamCity server had access to (deployment keys, signing certificates, artifact repository tokens) if there’s any ambiguity about whether it was exposed during the vulnerable window.

The pattern to actually fix

This is the second time in as many months a CI/CD tool has shipped an unauthenticated RCE in a component that exists specifically to talk to unauthenticated parties, whether that’s build agents checking in or webhook receivers accepting external calls. Those endpoints get less security review than login-gated ones because “nobody’s authenticated yet” reads as lower risk, when it’s actually the opposite: it’s the part of your attack surface an attacker doesn’t need credentials to reach at all.

If you’re running TeamCity, Jenkins, GitLab CI, or anything else that orchestrates your build pipeline, put “what does this tool expose without authentication” on your next security review agenda, not just “is it patched.” Patching CVE-2026-63077 closes this specific hole. It doesn’t tell you whether the next one is already sitting in a different unauthenticated endpoint on the same server. Teams that treat CI infrastructure with the same scrutiny as production, rather than as internal tooling, catch these before CISA does. If you want a second set of eyes on your build pipeline’s exposure, our team has run this kind of infrastructure audit for clients running exactly this stack.