JetBrains TeamCity CVE-2026-63077: Unauth RCE

JetBrains is urging customers to patch a critical flaw in its TeamCity build server that lets an unauthenticated attacker run operating-system commands on the host. Tracked as CVE-2026-63077 and rated 9.8 on the CVSS scale, the vulnerability affects all versions of TeamCity On-Premises. JetBrains published its advisory on July 27, 2026 and says it is not aware of active exploitation at the time of release — but the profile of the bug, and the value of the systems it lives on, make this one to patch immediately.

The vulnerability

CVE-2026-63077 is an unauthenticated remote code execution flaw. According to JetBrains, an attacker with HTTP or HTTPS access to a TeamCity server can bypass authentication checks and execute arbitrary operating-system commands on the machine — no account, no credentials, no prior foothold required.

The weakness lives in TeamCity’s agent polling protocol, the mechanism by which build agents check in with the server to receive work. Reports on the bug describe an attacker abusing that protocol path to sidestep the server’s authentication layer and reach command execution. Because the entry point is the same HTTP(S) interface teams use to reach TeamCity’s web UI, any server exposed to a network an attacker can touch is in scope — and many build servers are reachable from more of the corporate network, or the internet, than their owners assume.

The 9.8 severity reflects the familiar high-water combination: network-reachable, no authentication, low complexity, full code execution. The only reason it is not a perfect 10.0 is scoring nuance around impact scope; in practical terms, an unauthenticated path to running commands on a build server is about as serious as enterprise vulnerabilities get.

What TeamCity is — and why a build server is a crown jewel

TeamCity is a continuous integration and continuous delivery (CI/CD) platform. Its job is to take source code, build it, run tests against it, and ship the resulting artifacts toward production — the automated assembly line that sits between a developer’s commit and a running application. Understanding how CI/CD pipelines work is the key to understanding why a flaw here is so dangerous.

A CI/CD server is one of the most privileged and trusted systems an engineering organization runs. To do its job, it typically holds:

• Source code for everything the organization builds, often including private repositories the company never intends to expose.
• Deployment credentials — cloud API keys, container-registry tokens, SSH keys, and signing material — that let it push artifacts into production. These are exactly the secrets that a build system must manage carefully, and they are concentrated in one place.
• The build process itself, meaning the ability to inject code into artifacts before they are shipped, signed, and trusted by everyone downstream.

That last point is what elevates a build-server compromise from “a breached machine” to a software supply-chain risk. An attacker who controls the pipeline does not merely steal data; they can tamper with what gets built and delivered, planting malicious code inside trusted software that customers and internal systems will install without suspicion. Supply-chain incidents — from poisoned dependencies to malicious proof-of-concept code seeded on developer platforms — have repeatedly shown that the most efficient way to reach many victims is to compromise the thing they all trust. A CI/CD server is precisely that thing.

Disclosure and timeline

The vulnerability was reported to JetBrains privately on July 10, 2026 by security researcher Antoni Tremblay, through the company’s coordinated-disclosure process. JetBrains investigated, developed fixes, and published its advisory on July 27, roughly two and a half weeks later — a compressed but not unusual window for a critical, actively-developed product.

Crucially, JetBrains states it has no evidence of exploitation in the wild as of the advisory. That is the best-case starting position for defenders: a fix that lands ahead of known attacks. It is not, however, a reason to wait. Coordinated disclosure buys a head start, not immunity. Once an advisory names the affected component — here, the agent polling protocol — skilled researchers and attackers alike begin working backward from the patch to reconstruct the flaw. For a bug this severe on a product this widely deployed, the realistic assumption is that a proof-of-concept exploit will follow the advisory within days to weeks, and the population of unpatched, internet-exposed TeamCity servers is where that exploit will land first.

Fixed versions and mitigation

JetBrains has addressed CVE-2026-63077 in TeamCity 2025.11.7 and 2026.1.3. Administrators running On-Premises installations should upgrade to one of those releases as the primary remediation.

For teams that cannot upgrade immediately, JetBrains has published a dedicated security patch plugin that backports the fix, supported on TeamCity 2017.1 and later. That gives even organizations running older, long-lived installations a path to remediate without a full version jump — valuable, because build servers are notorious for being pinned to old versions that “just work” and are rarely touched for fear of breaking the pipeline.

TeamCity Cloud customers are not required to take any action; JetBrains has patched its hosted service directly. The exposure is specific to the self-managed On-Premises product.

Defenders should treat the fix as necessary but incomplete on its own:

• Upgrade to 2025.11.7 or 2026.1.3, or install the security patch plugin if you are on a supported older build.
• Reduce exposure. A CI/CD server rarely needs to be reachable from the public internet. Place it behind a VPN or restrict access to known networks so that even a future exploit has a smaller attack surface to reach — the same network-segmentation logic that zero-trust architectures apply to every high-value internal system.
• Rotate secrets stored in or reachable from TeamCity — deployment keys, registry tokens, signing credentials — if there is any doubt the server could have been reached before patching.
• Review build logs and configuration for unexpected changes, new administrative users, or unfamiliar build steps, which would be the fingerprints of tampering.

What it means

CVE-2026-63077 is a textbook critical vulnerability: unauthenticated, network-reachable, and code-executing, on a class of system that sits at the heart of how software gets built and shipped. The saving grace is timing — JetBrains fixed it before any known exploitation — but that advantage is temporary and depends entirely on how fast customers apply the update.

Who is exposed. Every organization running TeamCity On-Premises that has not patched. The flaw affects all On-Premises versions, so age is no protection; if anything, the oldest, least-maintained installations are the likeliest to be both vulnerable and internet-reachable. TeamCity Cloud users are covered by JetBrains’ own patching.

Why the stakes are higher than a typical RCE. Compromising a build server is not an endpoint; it is a pivot into the software supply chain. The attacker inherits source code, production credentials, and — most dangerously — the ability to alter artifacts before they are trusted downstream. That is the difference between losing one machine and poisoning everything that machine produces.

What to watch. The gap between JetBrains’ July 27 advisory and the appearance of a working public exploit. The pattern across 2026 has been relentless — critical infrastructure and developer-tooling flaws weaponized in days, sometimes hours, as the wider wave of same-day edge-device exploitation has shown. TeamCity operators still have the initiative today. The way to keep it is to patch before the proof-of-concept arrives, not after.