TeamCity CVE-2026-63077: The Agent Polling Protocol Is the Way In

The critical TeamCity flaw JetBrains patched last week has a specific entry point, and it matters for how you triage the fix: the exposure lives in the agent polling protocol, the channel a build agent uses to reach the server for work. In its advisory, JetBrains attributes CVE-2026-63077 to insecure deserialization of untrusted data (CWE-502) on that path, which an unauthenticated attacker with HTTP(S) reach to the server can drive to run operating-system commands as the server process. We covered the disclosure and the CVSS 9.8 rating when the patch shipped; this follow-up is about the mechanism and what it changes for defenders.

The detail is load-bearing because the vulnerable code sits on a service TeamCity treats as semi-trusted. Agents are supposed to talk to the server constantly, so the endpoint handling that conversation is meant to stay reachable — and, per JetBrains, it accepts serialized data it should not trust. That is why no login is required: the attack does not go through the human sign-in flow at all, it goes through the machine-to-machine channel.

Why the Polling Path Is the Attack Surface

In a normal TeamCity deployment, build agents poll the server over HTTP(S) to pick up jobs and report results. JetBrains describes CVE-2026-63077 as a deserialization flaw reached through that agent polling protocol, letting an attacker "bypass authentication checks and execute arbitrary operating system commands with the privileges of the TeamCity server process." Rapid7's write-up adds that a successful attacker could read stored credentials and undermine CI/CD pipeline integrity — the deployment keys and build secrets a server holds. (Confidence: the deserialization root cause and the polling-protocol entry point are stated by JetBrains and corroborated by Help Net Security; we are not reconstructing the exploit or the payload path.)

Our reading — labeled as editorial assessment, not new reporting — is that this changes the exposure question from "is my login page exposed" to "can an untrusted network reach the port my agents use." In many installs that is the same HTTP(S) port serving the web UI, often behind a reverse proxy on 443. So a server you assumed was low-risk because the UI sits behind SSO is still reachable on the exact channel this flaw abuses. The deserialization class is familiar territory; it is the same broad family as the SharePoint deserialization RCE we wrote up earlier this year, where a trusted-looking input became code execution.

A Polling-Port Exposure Check

Before scheduling the upgrade, the useful triage input is where the server's HTTP(S) interface — the one agents poll — can be reached from. A quick pass:

• Confirm the running TeamCity build and compare it against the fixed versions, 2025.11.7 (2025.11.x line) and 2026.1.3 (2026.x line). All On-Premises versions before these are affected.
• Identify every URL and port that resolves to the server's HTTP(S) endpoint, including reverse-proxy front ends and any load-balancer or ingress that forwards to it.
• Determine which of those paths are reachable from untrusted networks — the public internet first, then any flat internal segment that build agents and general corporate hosts share.
• Check whether agents connect over a network you control end to end, or whether the polling channel is exposed more widely than the agents actually need.
• Rank internet-reachable servers ahead of segmented ones. The flaw needs only HTTP(S) reach and no credentials, so network placement, not UI hardening, sets the priority.

If You Cannot Patch Immediately

The concrete defender takeaway: if you cannot move to 2025.11.7 or 2026.1.3 right away, restrict and segment access to the server's HTTP(S) interface so only trusted agents and operators can reach the polling channel, and apply JetBrains' security patch plugin. JetBrains says the plugin covers TeamCity 2017.1 and later and resolves this single CVE — a stopgap that closes the exposure while a maintenance window is arranged, not a replacement for the upgrade.

JetBrains' own hardening guidance points the same direction: limit access to internet-facing servers, run TeamCity with the minimum required operating-system privileges, put agents and the server behind a VPN or equivalent controls, and keep the server on a dedicated host separate from build agents. Read against the mechanism, that last item is more than tidiness — it narrows who can speak the polling protocol to the server in the first place. For internet-exposed servers that ran unpatched, our assessment is that patching closes the door but does not answer whether anyone came through earlier; reviewing access and rotating the credentials the server could reach is the proportionate second step, the same reasoning that made the Megalodon CI/CD workflow-backdoor campaign such a wide-blast-radius event.

Open Questions

Two items remain unresolved and we are not filling them in. First, exploitation status: JetBrains reported no known active exploitation at disclosure, and we found no source confirming that has changed — but a shipped fix is also a roadmap, and public analysis of the patched builds tends to shorten the time to a working exploit, so treat the flaw as if it could be exploited soon. Second, we could not confirm that CISA has added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog as of this writing (flagged open — verify against the live KEV list before citing it). Neither gap changes the action: the fix exists, the entry point is an unauthenticated network-reachable channel, and the servers behind it hold the keys to your pipeline.

Primary Documents

• JetBrains — Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)
• Rapid7 — CVE-2026-63077: Critical Unauthenticated RCE in JetBrains TeamCity
• SecurityWeek — Critical Code Execution Vulnerability Patched in TeamCity
• Help Net Security — JetBrains Fixes Critical Unauthenticated RCE in TeamCity On-Premises