JetBrains TeamCity On-Premises Critical Unauth RCE Patched (CVE-2026-63077, CVSS 9.8)

A critical CI/CD-platform flaw with no authentication barrier — JetBrains ships the fix, and the clock starts for every self-managed TeamCity server.

PRAGUE — JetBrains has patched a critical security flaw in TeamCity On-Premises, its self-hosted continuous-integration and continuous-deployment (CI/CD) server, that the company says an unauthenticated attacker could use to execute operating-system commands on a vulnerable server. Tracked as CVE-2026-63077 and rated 9.8 on the 10-point CVSS severity scale, the vulnerability affects every On-Premises version prior to the fix and was resolved this week in TeamCity 2025.11.7 and 2026.1.3.

The fix was reported by Help Net Security and The Hacker News on July 28, 2026, a day after JetBrains published its advisory. JetBrains said its vendor-hosted TeamCity Cloud was already patched and, for On-Premises customers unable to upgrade immediately, released a security patch plugin covering versions 2017.1 and later. This piece summarizes what JetBrains disclosed and what operators should verify; it does not reconstruct the flaw.

What JetBrains Disclosed

In an advisory published July 27, 2026, JetBrains described CVE-2026-63077 as a flaw that may allow an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and execute arbitrary operating-system commands. In plain terms: anyone who can reach the server's web interface could, per the vendor, run commands on the host without a valid account. That combination — no authentication, arbitrary code execution, and a network-reachable service — is what drives the 9.8 CVSS score.

JetBrains attributes the flaw to insecure deserialization of untrusted data in TeamCity's agent polling protocol, and credits security researcher Antoni Tremblay, who reported it privately on July 10, 2026 under coordinated disclosure. That deserialization root cause places CVE-2026-63077 in the same broad class as other recent server-side flaws, including the SharePoint deserialization RCE The CyberSignal covered earlier this year. The CyberSignal is not reproducing exploitation details.

Affected and Fixed Versions

The scope is broad. JetBrains states that all TeamCity On-Premises versions prior to the patched builds are affected, so operators cannot assume any install is safe without checking it against the fixed versions. The fix ships in two release lines: TeamCity 2026.1.3 for the 2026.x branch and TeamCity 2025.11.7 for the 2025.11.x branch.

For environments that cannot take a full upgrade immediately, JetBrains released a security patch plugin that it says applies to TeamCity 2017.1 and later — a bridge intended to close the exposure while a maintenance window is scheduled. The plugin is a stopgap, not a substitute for moving to a supported patched release, and it buys the same narrow window The CyberSignal has tracked before, as with the Apache HTTP/2 RCE that left operators days, not weeks.

What TeamCity Operators Should Verify (Cloud vs On-Premises)

The first question for any team running TeamCity is which product they operate. JetBrains says TeamCity Cloud — the vendor-hosted service — was already patched, so Cloud customers need take no action for this issue. The exposure sits entirely with On-Premises, the self-managed edition organizations run on their own infrastructure, where patching is the customer's responsibility.

For On-Premises operators the checklist is short: confirm the running version, compare it against 2025.11.7 or 2026.1.3, and upgrade or apply the security patch plugin if it falls short. Because the flaw is reachable without authentication, an On-Premises server exposed to the public internet is a higher-priority target than one reachable only inside a corporate network. Unauthenticated flaws in self-hosted developer platforms have a track record of drawing fast attention, as with the unauthenticated Gitea flaw disclosed earlier this year.

The CI/CD-Platform Pre-Auth-RCE Risk Pattern

A TeamCity server is not an ordinary application. As a CI/CD orchestrator it typically holds source code, build artifacts, signing material, and the deployment credentials used to push software into production. Code execution on that host reaches well beyond the box; it lands in the middle of an organization's software supply chain — which is why pre-authentication RCE in a build server draws the attention it does. The blast radius is the pipeline, not a single service.

CI/CD systems have become a favored route to reach many downstream projects at once — a dynamic visible in campaigns The CyberSignal has covered, from the Megalodon workflow-backdoor campaign across thousands of GitHub repositories to pipeline abuse elsewhere. CVE-2026-63077 does not require a supply-chain compromise to be serious, but the value of the target is what turns a patch notice into an urgent one.

Open Questions

Several details remain unresolved at publication, and The CyberSignal is not filling them in. JetBrains stated it had no evidence of active exploitation at the time of its advisory; whether that holds as the patched builds are analyzed is an open question, since public study of a fix can shorten the time to a working exploit. It is also not established how many On-Premises instances are internet-exposed, nor whether the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added the flaw to its Known Exploited Vulnerabilities catalog.

What is settled is the part that matters most for action: a critical, unauthenticated code-execution flaw in a widely deployed build server, with a fix already available. The reporting frames this as a patch-now event, not an active incident — upgrade to a fixed version or apply the security patch plugin, and treat internet-exposed On-Premises servers first.

The CyberSignal Analysis

The reported facts above come from JetBrains' advisory and the reporting on it; what follows is The CyberSignal's editorial reading. None of the judgments below are new reported facts.

Signal 01 — The Fix Exists, So the Clock Is the Threat

With a pre-auth RCE, the instinct is to ask how bad the flaw is; our reading is that the more useful question is how fast the patched builds propagate. JetBrains reported no known exploitation at disclosure, but a public fix is also a map: once 2025.11.7 and 2026.1.3 are compared against their predecessors, the effort to weaponize the flaw tends to drop. That is the recurring shape of self-managed patch stories — the exposure is the lag before operators apply the fix, not its absence.

The practical consequence is to treat CVE-2026-63077 like a known-exploited bug even though it is not yet listed as one. Operators who upgrade this week are out of the window; those who wait are betting that no one reverse-engineers the patch first.

Signal 02 — Exposure Placement Beats a Blanket Rule

Our assessment is that the single most useful triage input here is network placement. An On-Premises TeamCity server on the public internet is a categorically different risk from one reachable only inside a segmented build network, because the flaw needs only HTTP(S) reach and no credentials. Defenders who can enumerate which of their build servers are externally reachable can rank their patching accordingly rather than treating every instance as equally urgent.

This does not lower the priority of internal servers — insider reach and lateral movement still matter — but it tells a stretched team where to spend the first hour.

Signal 03 — Patch the Server, Then Rotate What It Held

The detail we find most durable is what a build server contains. Because a successful attack on this class of flaw would run code where deployment credentials and signing keys live, our view is that patching closes the door but does not, by itself, answer whether anyone walked through it earlier. For internet-exposed servers that ran unpatched, the disciplined follow-up is to review access and rotate the secrets the server could reach.

We would frame that not as alarm but as hygiene proportional to the target: the same reasoning that makes a CI/CD server a high-value objective makes credential rotation the natural second step after the upgrade — cheaper now than to reconstruct later.

Sources