Critical TeamCity flaw CVE-2026-63077 lets an unauthenticated attacker run commands on your build server

A build server is the one machine where a single remote code execution bug is never just one host. It holds the source, the secrets, the signing material, and the credentials that push your artifacts into production. On July 28, 2026, JetBrains disclosed exactly that kind of bug in TeamCity: CVE-2026-63077, a critical authentication bypass that lets an unauthenticated attacker with network access run operating system commands on the server. JetBrains rates it CVSS 9.8. On a continuous-integration server, that number is the floor, not the ceiling.

There is no sign yet that anyone is exploiting it. That is the good news and the deadline.

The bug: an unauthenticated path to command execution

According to reporting from The Hacker News and JetBrains' own advisory, the flaw lives in TeamCity's agent polling protocol, the channel build agents use to talk to the server. An attacker who can reach the server over HTTP or HTTPS can abuse that protocol to sidestep the authentication checks and run operating-system commands as the TeamCity server's own service account. No login, no token, no valid account.

With that foothold, an attacker can read TeamCity's data and configuration, pull the credentials it has stored to reach your repositories and deploy targets, alter server settings, and reach into the pipelines the server drives. That last item is the reason a build-server RCE deserves more alarm than its severity score: the machine's entire job is to run trusted code and ship the result.

The scope is broad. Every TeamCity On-Premises version is affected, and the company says its hosted Cloud instances were already patched. The on-premises fixes ship in builds 2025.11.7 and 2026.1.3. The flaw was reported to JetBrains by researcher Antoni Tremblay, and as of the July 28 disclosure there is no public proof-of-concept, no CISA Known Exploited Vulnerabilities listing, and no reported in-the-wild activity, per Security Affairs.

Your version number does not scope this. Reachability does.

Because every On-Premises release is affected, the usual first question, "which build am I on," tells you nothing about your risk. The only variable that changes your exposure is whether an unauthenticated stranger can reach the server's HTTP or HTTPS port. Plenty of TeamCity servers are reachable, because agents and developers need to reach them, and a fair number sit on the public internet with the login page facing the world.

So triage by reachability, not by version. If your TeamCity is only reachable from an internal network or a VPN, you have breathing room to schedule the patch. If its login page or REST API answers from the open internet, you are one request away from the vulnerable code path and you should treat this as an emergency. JetBrains' guidance says the same: restrict network access, require a VPN for internet-facing instances, and stop exposing the login page and REST API publicly. That advice is the fastest risk reduction available to anyone who cannot deploy the patch this hour.

Why "no exploit yet" is a countdown, not a reprieve

Authentication-bypass bugs are among the fastest classes to weaponize, and the reason is the fix itself. A patch diff shows a researcher the exact check that was added and, by implication, the check that was missing before. For a flaw whose whole nature is "skip the check," the patch is close to a map. So the quiet window between disclosure and a working exploit for a 9.8 auth bypass tends to be measured in days, not months.

We made the same argument about Adobe's max-severity ColdFusion flaws that shipped without a public exploit: the absence of an exploit is the window you patch in, not evidence you can wait. Read "none observed" as a timer that started on disclosure day. The teams that patch while it is quiet never have to find out how short the window was.

Patch now, or take the server off the internet

The order of operations is simple, and reachability decides how fast you move.

If you run TeamCity On-Premises, update to 2025.11.7 or 2026.1.3. If you are on an older release you cannot jump forward quickly, JetBrains shipped a security patch plugin that backports just this fix to versions as old as 2017.1. The existence of that plugin is a quiet admission that many production build servers run years behind the current release. If that describes yours, the plugin is the bridge, not an excuse to skip the fix. And if you cannot touch the server in the next hour, gate it: put it behind a VPN or an IP allowlist so the vulnerable endpoint is not reachable before authentication.

While you close the window, watch the box. A build server is a predictable machine, which makes anomalies loud. Treat any unexpected child process spawned by the TeamCity server process as hostile until proven otherwise, a shell, curl, wget, or a scripting interpreter it has no reason to launch. Flag new administrator accounts or access tokens you did not create, configuration changes you cannot attribute to a person, and outbound connections from the build host to addresses it has never talked to. On a server whose entire purpose is to run trusted code, the tell is code running that no pipeline scheduled. Our writeup of a poisoned scanner that walked cloud credentials off a build server is the same lesson from the compromise side: the crown jewels were the stored secrets, not the box.

The takeaway is not only "patch TeamCity," though you should. It is that a build server earns the same paranoia as a domain controller. It is a single point from which an attacker can rewrite everything you ship, and it is too often left reachable from the open internet with a login page for anyone to poke. CVE-2026-63077 is this cycle's reminder. Treat the fix as routine maintenance and you will be fine. Treat the CVSS score as the whole story and you may learn, from an incident, that 9.8 was the beginning of the math.