CRITICAL: JetBrains TeamCity Pre-Auth RCE Hits All On-Premises Versions

Build servers sit in a strange blind spot. They are not treated like crown jewels, so they rarely get the scrutiny a domain controller gets. Yet they hold the signing keys, the deployment credentials, the cloud tokens, and the source code for everything the actual crown jewels run on. JetBrains has just handed the industry another reminder of why that arrangement is a problem.

On July 27 the National Vulnerability Database published CVE-2026-63077, an unauthenticated remote code execution flaw in TeamCity On-Premises carrying a CVSS 3.1 base score of 9.8. JetBrains fixed it in 2025.11.7 and 2026.1.3. Every version of TeamCity On-Premises released before those two is affected, which is an unusually blunt way for a vendor to admit there is no safe older branch to sit on.

What actually broke

The flaw lives in the agent polling protocol, the mechanism build agents use to check in with the central server and ask for work. NVD classifies it as CWE-502, deserialization of untrusted data, and that classification tells most of the story. The server accepts data over that channel and reconstructs objects from it before establishing that whatever is on the other end has any business talking to it. An attacker who can reach the server over HTTP or HTTPS abuses that path to skip authentication entirely and run operating system commands with the privileges of the TeamCity server process.

The vector string reads CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Reachable over the network, low attack complexity, no privileges required, no user interaction, and a complete loss of confidentiality, integrity, and availability. The only thing keeping it off a perfect ten is the unchanged scope, meaning the damage stays inside the vulnerable component instead of spilling into a separate security authority. That distinction is academic when the vulnerable component is the machine that compiles and signs your software.

Antoni Tremblay reported the issue privately to JetBrains on July 10, and JetBrains shipped fixes seventeen days later. That is a respectable turnaround for a bug of this class, and coordinated disclosure worked the way the process is supposed to work. At the time the advisory went out, JetBrains said it was not aware of any active exploitation. Nobody should read that as permission to schedule this for next quarter.

The history matters more than the current exploitation status

TeamCity has been through exactly this before, twice, and both times the gap between disclosure and mass exploitation was measured in days.

CVE-2023-42793 was an authentication bypass leading to remote code execution. Within weeks of its September 2023 disclosure, Russian state actors tracked as APT29 were working through internet-facing TeamCity servers, a campaign serious enough to earn a joint advisory from CISA, the FBI, and the NSA that December. North Korean operators from Lazarus and Andariel were exploiting the same flaw in parallel. When a single build server bug attracts two separate nation-state programs, it is because the target class is genuinely valuable and not because it happened to be convenient.

CVE-2024-27198 and CVE-2024-27199 arrived in March 2024. Public proof of concept code appeared almost immediately and what followed was a free for all. Trend Micro documented Jasmin ransomware deployments off the back of it. BianLian affiliates joined in. Cryptominers, remote access trojans, and Cobalt Strike beacons all rode the same authentication bypass, and researchers logged exploitation within roughly a day of the technical details going public.

The pattern is consistent enough that the reassuring line in the current advisory should be read as a countdown rather than an all clear. CVE-2026-63077 is a deserialization flaw in a documented protocol, on a product with a large installed base, backed by a decade of public exploit development. Somebody is going to diff the patch. That work has almost certainly already started.

Who needs to move and how fast

If you run TeamCity On-Premises, you are affected. There is no version floor that saves you and no configuration JetBrains has identified as inherently safe. Move to 2025.11.7 if you are on the 2025.11 branch or 2026.1.3 if you are on 2026.1, and treat it as this week's work rather than this month's.

Anyone who cannot upgrade immediately has a real option instead of a hand wave. JetBrains published a security patch plugin covering versions all the way back to 2017.1, which is a genuinely generous support window for a critical fix. Installing it requires a server restart only on versions 2017.1 through 2018.1. If you are running something that old on an internet-facing build server, the restart is the least of your worries, but the plugin still closes the hole.

TeamCity Cloud customers have nothing to do. JetBrains patched its hosted infrastructure ahead of disclosure.

The last piece of vendor guidance deserves more weight than it usually receives, which is that a TeamCity server has no business being reachable from the open internet. Put it behind a VPN or an identity aware proxy. Build servers need to accept connections from agents and developers, and both of those populations are known and enumerable. The agent polling protocol being exposed to arbitrary internet hosts is precisely what turns an ugly bug into an emergency.

Detection and cleanup

Patching closes the door. It says nothing about whether somebody already walked through it, and because the underlying flaw shipped in every version of the product, the exposure window for an internet-facing server is not seventeen days. It is however long that server has been online.

Start with the server logs and look for unexpected requests against agent endpoints, especially from addresses that do not match your known build agents. Examine the TeamCity server process and what it has spawned, since command execution here inherits the service account and the useful evidence tends to be child processes rather than web shells. Audit the administrator list along with any recently created users or access tokens. Then walk your build configurations looking for steps nobody remembers adding, because quietly editing a build definition is the most efficient way to turn one compromised server into compromised software delivered to every customer downstream.

After that, rotate. Every secret TeamCity holds should be considered exposed if the server was internet-facing and unpatched, and that inventory is always longer than anyone expects. Deployment keys, cloud provider tokens, artifact repository credentials, code signing material, and database passwords all accumulate quietly in build configurations over the years, and a rotation that stops at the admin password has not actually accomplished anything.

The MSP angle

This is the cleanest opening you will get all quarter for a CI/CD security conversation with development heavy clients, because the flaw is easy to explain and the blast radius sells itself. A build server compromise is a supply chain compromise, and any client shipping software to their own customers immediately understands what that means for their contracts, their audit posture, and their cyber insurance renewal.

Lead with an emergency patch engagement and convert it into an external attack surface assessment, because the clients running an internet-facing TeamCity server are usually the ones who do not know they are running one. The follow-on retainer writes itself as build pipeline hardening and secrets rotation, two projects nearly every development organization has been meaning to get to and nobody has ever scheduled.