JetBrains disclosed CVE-2026-63077 on July 27, a critical unauthenticated remote code execution vulnerability in TeamCity On-Premises, the CI/CD server used to orchestrate builds, tests, and deployments across a large share of the enterprise DevOps market. The flaw carries a CVSS v3.1 score of 9.8 and requires nothing from an attacker beyond HTTP(S) reachability to the server — no credentials, no session token, no user interaction. JetBrains says it has no evidence of active exploitation as of publication, but the bug affects every TeamCity On-Premises version and sits squarely in the build pipeline, making it a high-value target the moment a public PoC lands.

What’s Broken

The root cause is insecure deserialization (CWE-502) in TeamCity’s agent polling protocol — the channel build agents use to check in with the server for job assignments and configuration updates. That endpoint is designed to be reachable without authentication, because build agents themselves authenticate via a separate mechanism after the initial handshake. CVE-2026-63077 abuses that design: an attacker sends a crafted payload to the polling endpoint, the server deserializes it as if it came from a legitimate agent, and the payload executes as arbitrary OS commands with the privileges of the TeamCity server process.

Because the polling endpoint has to be network-reachable for real build agents to phone home, there’s no authentication layer sitting in front of it to block a malicious request — the vulnerability lives in the protocol’s trust assumption, not in a login form that can simply be hardened. Researcher Antoni Tremblay reported the flaw privately on July 10; JetBrains shipped a fix and published the advisory 17 days later, stating no in-the-wild exploitation was observed at disclosure time.

Impact

Affected: all TeamCity On-Premises versions prior to the patched releases. TeamCity Cloud is not affected and requires no customer action.

The blast radius here is worse than a typical unauthenticated RCE because of what TeamCity holds. A compromised TeamCity server typically has:

  • Source code access across every project it builds
  • Stored credentials and secrets — cloud provider keys, artifact repository tokens, signing keys, deployment credentials — needed to push builds to production
  • Write access to build artifacts, meaning an attacker with server-level RCE can tamper with binaries or packages before they’re signed and shipped downstream

That combination turns a single unauthenticated request into a potential software supply-chain compromise: an attacker doesn’t need to touch any individual customer’s infrastructure if they can poison a build at the source. Any organization running an internet-facing or otherwise broadly reachable TeamCity On-Premises instance — including instances only exposed to a corporate network but reachable from a compromised endpoint — should treat this as an active risk to their release pipeline, not just to the TeamCity host itself.

Mitigation

  1. Upgrade immediately to TeamCity 2025.11.7 or 2026.1.3, both of which contain the fix.
  2. If you can’t upgrade right away, JetBrains has published a dedicated security patch plugin covering versions 2017.1 and later that addresses only this CVE. On 2018.2+ the plugin can be installed without a server restart; versions 2017.1–2018.1 require a restart after installation. The plugin is a stopgap, not a substitute for the full upgrade.
  3. Restrict network exposure of the TeamCity server and its agent polling endpoint to only the build agents that need to reach it — it should never be reachable from the general internet, and ideally not from the broader corporate network either.
  4. Rotate credentials stored in TeamCity (cloud keys, deployment tokens, signing material) if you have any indication of prior compromise or if the server was internet-facing before patching, since RCE at this layer implies potential secret exposure regardless of whether exploitation is confirmed.
  5. Audit recent build and deployment activity for anomalies — unexpected build triggers, modified build configurations, or artifacts that don’t match expected build agent provenance — since a supply-chain-style compromise here would look like a legitimate build until the artifact itself is inspected.

References