CVE-2026-63077, JetBrains TeamCity On-Premises: unauthenticated RCE through the agent-polling protocol, every on-prem version affected (CVSS 9.8)

JetBrains' advisory is short on mechanism by design and unambiguous on reach: an unauthenticated attacker with HTTP(S) access to a TeamCity On-Premises server can bypass authentication checks and run arbitrary operating-system commands with the privileges of the TeamCity server process, and every On-Premises version ever shipped is affected (JetBrains, 2026-07-27). The reachable surface is the agent-polling protocol, the channel distributed build agents use to check in with the central server for job assignments and configuration. JetBrains' own framing is that exploitation of the flaw requires no authentication and that the attacker bypasses authentication checks by way of that protocol, so there is no credential, session, or user interaction standing between a network-reachable server and command execution (JetBrains, 2026-07-27). The flaw was reported privately on 2026-07-10 by Antoni Tremblay, and JetBrains states it is not aware of any active exploitation as of publication (JetBrains, 2026-07-27); the CVE record filed by JetBrains as its own CNA carries the flaw as CWE-502, deserialization of untrusted data, at CVSS 9.8 (MITRE CVE Record, 2026-07-27).

The reason this warrants moving ahead of the ordinary patch queue is what a build server is, not the score. A TeamCity server holds the credentials its pipelines deploy with, the signing material its artifacts are stamped with, and write access to the outputs every downstream consumer trusts, so command execution as the server process converts into a durable ability to alter what future builds produce. Public exploitation of the present flaw has not been observed, and the honest reading of that is a clock rather than an all-clear, JetBrains withheld the gadget chain, but "all versions affected" plus "no authentication" plus a widely deployed, easily fingerprinted product is a combination that historically closes quickly once someone reconstructs the path.

Detection: the observable is in the web-server or reverse-proxy access log in front of TeamCity and in process-creation telemetry on the server host. Requests to the agent-polling endpoint arriving from addresses that are not your registered build agents are the first signal, and the second (the one that matters if the first was missed) is any child process spawned by the TeamCity server process that is not part of a build it was asked to run: shells, interpreters, or network utilities parented to the server rather than to an agent's build step. Triage: the agent-polling endpoint legitimately receives continuous check-in traffic from your build fleet, so request volume to it discriminates nothing on its own. Two things do. The source address set is finite and knowable; your registered agents are an inventory, so polling traffic from anything outside it is the anomaly. And on the server host, legitimate command execution belongs to agent processes running build steps; the server process itself spawning an interpreter or a network utility is not a quieter version of normal activity but a different thing entirely. Hardening: apply 2025.11.7 or 2026.1.3, or the security-patch plugin on 2017.1 and later, and treat the agent-polling interface as an internal service, if the only reason it faces the internet is that some agents live outside the network, a VPN or reverse tunnel for those agents removes the exposure that makes this flaw reachable at all.