JetBrains TeamCity's unauthenticated 9.8: CVE-2026-63077 turns the channel you trust into RCE

A build server is not one box

On July 27, 2026, JetBrains disclosed CVE-2026-63077 — an unauthenticated remote code execution flaw in TeamCity On-Premises. It is rated CVSS 9.8, and all an attacker needs is network reach to your build server. That server is where your organisation keeps its signing keys, deploy credentials and source code — which is why one RCE here is really a foothold into everything TeamCity builds and ships.

The flaw lives in TeamCity's agent polling protocol — the channel build agents use to talk to the central server — and is classified CWE-502, deserialization of untrusted data. A crafted message to that endpoint is deserialized before the sender ever authenticates, and the server ends up executing attacker-controlled code in the context of the TeamCity server process.

The channel you were told to trust

TeamCity agents poll the server: the build agent opens the connection outward and asks for work. Because the agent initiates that TCP connection, it is tempting to assume the protocol is an internal, agent-only affair. It is not. The server still receives, parses and responds to whatever arrives on that channel — and it does so before it has established who is on the other end.

Why a foothold here is a supply-chain foothold

TeamCity has been a target before

This is not TeamCity's first critical, unauthenticated bug — and the last ones did not stay theoretical. CVE-2023-42793, an authentication-bypass-to-RCE, was mass-exploited and abused by nation-state actors to backdoor build servers. CVE-2024-27198, another auth bypass, was weaponized within days of disclosure. Both now sit at the very top of the EPSS scale.

Am I affected?

# External recon: is a TeamCity server reachable, and what build is it?curl -sk https://teamcity.example.com/login.html \  | grep -oiE 'TeamCity [0-9]{4}\.[0-9.]+'# Compare the result against the fixed builds: 2026.1.3 / 2025.11.7# (the footer/version string format varies by release — adjust the pattern)

Fix it: patch, or isolate then patch

1. Inventory every TeamCity On-Premises server — including forgotten and staging instances.
2. Prioritise anything reachable from the internet; patch those first.
3. Upgrade to 2026.1.3 / 2025.11.7, or apply the security patch plugin if you cannot upgrade immediately.
4. Rotate secrets the server can reach: signing keys, deploy tokens, VCS and cloud credentials.
5. Review recent build logs and artifacts for tampering before trusting new releases.

What to watch while you patch

There is no public proof-of-concept and no confirmed in-the-wild exploitation as of this writing — which also means there is no ready-made signature to drop into your IDS. Detection here is behavioural, not signature-based.

• Unexpected child processes spawned by the TeamCity server process (shells, interpreters, network tools).
• Agent-polling traffic from source IPs that are not your known build agents.
• New or modified build steps, plugins or scheduled tasks you did not create.
• Outbound connections from the build server to unfamiliar destinations.

Data as of 2026-08-04live record →