The flaw sits in the agent polling protocol, a communication channel normally used by build agents (automated workers) to check in with the TeamCity server. The server failed to properly enforce authentication checks on this channel, meaning an attacker can send requests through it as if they were a legitimate agent and reach privileged functionality they should never be able to access. Think of it like a staff entrance with a broken lock — the front desk checks every visitor, but this side door waves anyone through.

An attacker with HTTP or HTTPS access to the TeamCity server sends crafted requests through the agent polling endpoint, bypassing authentication entirely. Once past that check, they can issue operating system commands that run with the same permissions as the TeamCity server process itself — which in many deployments means access to stored credentials, build configurations, source code, and deployment pipelines. No user interaction and no existing account is required.

1. Review TeamCity server logs for unexpected or unauthenticated requests to agent polling endpoints, particularly from unfamiliar IP addresses.
2. Check for unexpected outbound connections from the TeamCity host, especially to unusual destinations.
3. Audit recently modified build configurations, stored credentials, or administrator accounts for changes you did not make.

1. Upgrade to TeamCity On-Premises version 2025.11.7 or 2026.1.3 immediately.
2. If upgrading now is not possible, install JetBrains' security patch plugin (available for versions 2017.1 and above) as an interim measure.
3. Place the TeamCity server behind a VPN or restrict network access so it is not reachable from the public internet.

The server processes incoming serialized data (packaged data sent across a network connection) from the agent polling channel without confirming whether the sender is actually a legitimate, authenticated build agent. When software trusts the shape of data rather than its verified origin, an attacker can craft a malicious payload and submit it as though it came from a trusted source.

An unauthenticated attacker who can reach the TeamCity server's network port sends a specially crafted serialized payload over the agent polling protocol. The server deserializes it without authentication checks, executing arbitrary operating system commands at whatever privilege level the TeamCity process runs under. No account credentials are required. A successful hit can expose stored credentials, tamper with build configurations, and compromise software pipelines that push code into production environments.

1. Look for unexpected process executions spawned by the TeamCity server process in your endpoint logs.
2. Monitor agent polling protocol traffic for connections from IP addresses outside your known build agent pool.
3. Review TeamCity audit logs for configuration changes or credential access that does not correspond to a known user session.

1. Apply the patched TeamCity release immediately — FCEB federal agencies must do so by August 8, 2026.
2. Restrict network access to the TeamCity server so only authorised build agents and administrators can reach it.
3. Review and rotate any credentials stored within TeamCity as a precaution.