Dora NodaOn July 27, 2026, JetBrains disclosed a CVSS 9.8 unauthenticated remote-code execution flaw in the server that builds and ships your code. CVE-2026-63077 affects all TeamCity On-Premises versions: anyone who can reach the server over HTTP(S) — no credentials, no user interaction — can exploit the agent polling protocol to bypass authentication and run arbitrary OS commands as the TeamCity server process. The flaw was privately reported on July 10 by researcher Antoni Tremblay, fixed on July 25 in releases 2025.11.7 and 2026.1.3, and disclosed on July 27; by August, JetBrains confirmed reports of active exploitation, CISA had added it to the Known Exploited Vulnerabilities catalog, and by late September it was flagged as abused by ransomware gangs, with Shadowserver still tracking over 160 unpatched internet-exposed servers.
The instinctive question after an RCE advisory is "did they get root on the box?" On a build server that is the wrong question, because the box itself is nearly worthless and everything it holds pointers to is not. This post inventories exactly what a popped CI server costs — instantiated for a self-hosted fleet, not in the abstract — and then shows why ephemeral, narrowly-scoped build containers are a structurally different trust model rather than a patched version of the same one.
The blast-radius inventory: what the server process can touch, you have lost
JetBrains' own impact statement is unusually direct: depending on the server process's privileges, a successful attack could expose TeamCity data, configurations, and stored credentials, modify server state, and compromise the integrity of build artifacts and downstream CI/CD pipelines. Read that as three incidents stacked into one CVE — a credential breach, an integrity breach, and a supply-chain breach. Here is the inventory, with each asset class translated into what it means for a Cluster-API-managed fleet whose CI holds the keys to the machines:
| Asset the process can touch | What the attacker gains | Fleet-instantiated cost |
|---|---|---|
| Stored VCS credentials (deploy keys, tokens) | Read and rewrite source across connected repos | Attacker pushes to the repos your fleet deploys from |
| Stored cloud credentials (Hetzner/cloud API keys) | Provision, mutate, or destroy infrastructure as you | Attacker-driven node provisioning inside your own account |
| Registry tokens + artifact-signing material | Publish trusted images and sign them | Fleet pulls attacker-built images that verify cleanly |
| Mutable server state (build configs, steps) | Silent pipeline edits nobody reviews | One added build step in an unreviewed library job |
| Build artifacts + downstream pipelines | Poisoned outputs flowing to production | Every downstream deploy carries the compromise forward |
Two properties make this worse than a typical server compromise. First, everything in the table is useful after the patch: rotating nothing means the attacker keeps every credential they exfiltrated on day one, and rebuilding nothing means every artifact they touched stays poisoned. Patching restores availability, not trust. Second, the blast radius crosses the boundary teams assume exists between "CI tooling" and "production infrastructure" — on a self-hosted fleet that deploys from its own CI, there is no such boundary, only credentials.
Note what JetBrains recommends as the durable posture, because it concedes how exposed these servers normally are: limit network access to trusted networks, run the server with minimum OS privileges, put internet-facing servers behind a VPN or additional security layer, and run the server on dedicated hosts separate from build agents. Every one of those is compensating control for an architecture whose core design — a long-lived, network-reachable daemon holding every credential — is the thing the CVE exploited.
How the entry worked: an agent endpoint that must stay reachable
The exploit chain is short and worth stating exactly: an unauthenticated remote HTTP(S) request reaches the agent polling protocol endpoint, the server deserializes the attacker's data (XStream deserialization of untrusted data, CWE-502), authentication checks are bypassed, and arbitrary OS commands execute with the privileges of the TeamCity server process. No login, no agent registration, no foothold required — network reachability is the vulnerability's only precondition.
The uncomfortable part is that the reachable endpoint is not a misconfiguration; it is the architecture. TeamCity's default agent transport is unidirectional by design: build agents open outbound HTTP(S) connections to the server and poll for work, so operators never have to let the server reach into agent networks. That is a genuine security improvement — but it means the endpoint accepting agent traffic must be reachable by anything that runs builds, and it speaks a serialized-object protocol. The polling endpoint cannot be firewalled down to nothing without breaking builds, which is exactly why JetBrains' first recommendation is network restriction to agent subnets rather than anything stricter.
If you run TeamCity, the vendor's August follow-up gives concrete hunt indicators. Review server logs for com.thoughtworks.xstream.converters.ConversionException, which may indicate an attempted or successful exploit; on already-patched servers, com.thoughtworks.xstream.security.ForbiddenClassException means an attempt was made and blocked. Also review the unauthorized-agents list for unexpected entries, particularly names beginning with scan — those can be safely removed, though their displayed dates don't mark when the attempt happened. Log timestamps, not agent dates, scope the incident window.
The precedent pattern: third strike against the asset class
This is the third time in three years that a critical pre-auth flaw in this product has been the interesting thing on the internet, and the two precedents show what the window between advisory and mass compromise looks like.
September 2023 — CVE-2023-42793, exploited by a nation-state. Russia's SVR, tracked as APT29, exploited the flaw at scale; in December 2023 the FBI, CISA, and NSA published advisory AA23-347A reporting over 100 compromised TeamCity servers across the US, Europe, Asia, and Australia. The advisory's assessment of why an intelligence service bothers with a CI server remains the clearest statement of the threat model anyone has written: access to a TeamCity server gives an actor "access to that software developer's source code, signing certificates, and the ability to subvert software compilation and deployment processes." Post-exploitation on victim networks included credential dumping, lateral movement, hidden admin accounts, and C2 tunneled through cloud-storage APIs.
March 2024 — CVE-2024-27198, exploited by everyone within hours. GreyNoise saw exploitation attempts from more than a dozen unique IPs the same day the auth bypass was disclosed; LeakIX counted roughly 2,700 unpatched instances one day and about 1,700 the next — of which around 1,400 already showed rogue user creation, three to three hundred accounts per server. The payloads that followed were unglamorous commodity crime: Jasmin ransomware, BianLian activity, XMRig miners, Spark RAT. Roughly 80% of the exposed population fell within about 48 hours of the advisory — not to a nation-state, but to whoever ran the public PoC first.
The pattern is the point. Each incident differs in vector — auth bypass, then auth bypass again, now deserialization through the agent protocol — but the payoff is identical every time, because the payoff is a property of where the CI server sits, not how the attacker got in. Defending "the CI server" as one asset misses it; the thing to defend is every credential and artifact the CI process can touch.
A structurally different trust model: ephemeral builds vs the long-lived daemon
Compare the two architectures as full systems — daemon plus its persistent stored credentials on one side, ephemeral per-build containers plus a separately hardened orchestrator and registry on the other (the orchestrator half gets its honest accounting in the next section):
| Property | Long-lived CI daemon (TeamCity-class) | Ephemeral per-build containers (git-push PaaS) |
|---|---|---|
| Credential lifetime | Years: every credential the server will ever need, stored on disk | Minutes: per-build, narrowly-scoped tokens minted at build start |
| Network reachability | Always on, HTTP(S) reachable by agents — and attackers | Build containers are not network services; nothing polls them |
| What one compromise yields | Every stored credential + mutable state + artifact history | The single build's scoped tokens, expiring within minutes |
| What patching restores | Availability only; trust needs rotation + artifact rebuild | The blast radius was already bounded by design |
| Agent protocol attack surface | A permanent deserializing endpoint (this CVE) | No agent protocol at all; the scheduler pushes work inward |
The difference that matters is not "containers versus VMs" — it is where credentials live and how long they live there. A CI daemon is a credential warehouse with a network port: compromise the process and you inherit its whole collection, accumulated over years, valid until someone rotates each one. An ephemeral build is a credential dead-end: the tokens exist for the build's duration, authorize only that build's narrow actions (pull this repo ref, push this image tag), and expire whether or not anyone remembers them. There is no flag to forget, no tier to misclassify, no central process whose privileges define the blast radius — because the blast radius was decided at token-minting time, per build, by policy rather than by memory.
This is also why the "restrict to agent subnets" guidance, correct as it is, treats a symptom. It shrinks who can reach the warehouse without changing the fact that the warehouse holds everything. Ephemeral builds invert the equation: even a fully compromised build container yields tokens that are already dead or dying, scoped to actions the attacker could likely have performed through the front door anyway.
The honest half: what ephemeral builds don't fix
Ephemeral builds delete the credential warehouse; they do not delete trust. Some component still mints the per-build tokens, schedules the containers, stores the images, and holds the deploy keys — and that orchestrator-plus-registry core deserves the same Tier-0 suspicion the CI daemon just earned. A post that pretends otherwise is selling a product, not a model. Four things the PaaS operator still has to get right:
First, per-build identity must be real, not decorative. If every build mints tokens from one shared service account with broad registry and cloud rights, you have rebuilt the warehouse with extra steps. Each build needs an identity whose permissions cover exactly its job — this repo ref, this image repository, this environment — and nothing else.
Second, artifact signing and verification must close the loop the 2023 incident pried open. Ephemeral builds bound credential blast radius, but a compromised build step can still emit a malicious image; only signatures verified at deploy time (with the signing keys living outside any build container) turn "the build produced this" into a checkable claim rather than an assumption.
Third, provenance has to be recorded where attackers can't rewrite it. Build attestations — which source ref, which base image, which build identity produced this artifact — belong in an append-only record the build itself cannot modify. Otherwise incident scoping after a bad build is archaeology.
Fourth, the orchestrator's own network posture needs the JetBrains treatment: scheduler and registry reachable only from the networks that require them, least-privilege service accounts, dedicated hosts or tenancies separated from tenant workloads. The CVE didn't break this layer, but the threat model it demonstrates — unauthenticated network input reaching privileged infrastructure — applies to every control plane, including a PaaS's.
None of that is an argument for keeping the warehouse. It is the price of the alternative being actually better rather than merely newer: ephemeral builds shrink the blast radius to one build's scoped tokens, and the operator's remaining job is keeping the mint, the registry, and the deploy path worthy of the trust they still hold.
What to do this week
If you run TeamCity On-Premises, the order of operations is: upgrade to 2025.11.7 or 2026.1.3 immediately, or install the security patch plugin (available for 2017.1 and later, automatic on 2024.03+) as a bridge — then restrict the server's HTTP(S) port to agent subnets and the admin VPN, confirm the service runs as a low-privilege OS account, hunt the logs for XStream exception strings and the agents list for scan* entries, rotate every stored credential (assume exfiltration, not just access), and verify or rebuild artifacts produced during the exposure window. Patching without rotation restores service while leaving the attacker holding working keys.
Wherever your builds run, port the structural lesson: shrink credential lifetime until a stolen token is useless before anyone notices, scope each build's identity to exactly its job, sign artifacts with keys no build can reach, and record provenance somewhere builds can't rewrite. And treat the build pipeline as Tier-0 infrastructure in the asset inventory — governed, monitored, and pentested like the identity system it effectively is — because CVE-2026-63077 is the third demonstration in three years that attackers already do.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
