An attacker with no credentials, holding only HTTP(S) access to the server, can run operating-system commands on a JetBrains TeamCity On-Premises installation. This is CVE-2026-63077, a 9.8-out-of-10 flaw that needs no username, no password and no interaction at all. And it does not land on just any server: it lands on the machine that builds, signs and ships your software.
JetBrains patched it on 27 July 2026, following a private, coordinated report. Exploitation came afterwards, against servers that had not updated, and it was enough to land the flaw on CISA's KEV catalogue of exploited vulnerabilities. That order — patch first, attacks later — changes how the case should be read.
This article explains, from a defender's point of view, what can be exploited and since when, why a build server is such a prized target, how to spot signs of compromise and how to close the door. It contains no exploit code.
What is CVE-2026-63077, and why is it critical?
The flaw is a deserialization of untrusted data —CWE-502— in TeamCity's agent polling protocol, the exchange between the server and the machines that run the builds. That channel processes serialized objects with the XStream library, and a crafted request lets the server reconstruct and run logic chosen by the attacker. The result is unauthenticated remote code execution, with the privileges of the TeamCity process itself.
It affects every TeamCity On-Premises version released before the fixes. The vendor-managed offering is out of scope for this advisory, because JetBrains administers and updates that server; the problem belongs to whoever runs their own instance. With a CVSS of 9.8, no authentication requirement and a high-value target behind it, it is an immediate patching priority.
The timeline: patch first, exploitation later
The sequence matters. On 27 July JetBrains released the fixed versions — 2026.1.3 and 2025.11.7 — after receiving the report through a private channel. By 28 July, specialist coverage was already reporting the patch. In the following days, exploitation attempts against unpatched servers appeared, and on 5 August CISA added the vulnerability to the KEV — raising its exploitation assessment from “none” to “active” — with a remediation deadline for US federal agencies of 8 August.
That timeline puts the case in perspective. This was not a zero-day exploited before any defence existed: there was coordinated disclosure, an available patch and a window to apply it. What pushed the vulnerability onto the KEV was not the absence of a fix but the number of instances still running without one. The lesson repeats: the window between patch and exploitation is measured in days, not weeks.
How it works, at a conceptual level
The technical analysis from Rapid7 describes the cause without turning it into a recipe. When servicing unauthenticated agent requests, the server built an XStream allowlist meant to restrict which Java classes could be deserialized; the trouble is that it added TeamCity's protocol classes without first removing the library's default permissions. That list, intended to be restrictive, left enough of a gap to chain objects together and reach execution.
The fix is as telling as the flaw: the patched version places a “permit nothing” rule before the allowlist, so that only what is explicitly authorised is accepted. It is the recurring pattern of insecure deserialization — an allowlist that does not start from deny-by-default — the same underlying class of flaw we saw in the Fastjson zero-day. This is not one vendor's exotic slip but a well-known trap for anyone who processes serialized objects arriving from outside.
That is why the technical breakdown stops here, at the “what makes it possible” rather than the “how it is built”: the detail of the gadget chain belongs to defensive research, not to a reproducible guide.
Why is a build server a high-value target?
A continuous-integration and delivery server is not just another server. It is where deployment credentials, production access secrets, artefact-signing keys, source code and artefact registries all converge. Whoever controls that machine does not merely gain a system: they inherit the keys to the entire software assembly line.
That is why the impact is a supply-chain one. Compromising the CI/CD lets an attacker inject code into builds that are then distributed to customers and other internal systems, sign malicious artefacts as if legitimate, or steal the secrets that open production. It is the same logic that turned a forgotten package into a problem for hundreds of projects in the easy-day-js npm supply-chain attack, except that here the entry point is the build infrastructure itself.
How do you detect exploitation?
Because the vector is a request to the agent channel, detection concentrates on how the server behaves after receiving it. These are the signals worth hunting, correlated rather than viewed in isolation.
The most direct is unexpected child processes hanging off the TeamCity process: a build server that suddenly launches a shell, an interpreter or network utilities is an anomaly that rarely has a benign explanation. Alongside it, watch for outbound connections to unknown destinations — possible C2 — the creation of new administrator users or access tokens, and unexplained changes to build configurations or scripts.
Since the patch dates from 27 July, any retrospective review should cover from that date: anomalous requests to the agent polling endpoint from unauthenticated sources, new files on the server and altered artefacts. Turning these indicators of compromise into repeatable hunts — and combing the historical logs for that activity — is exactly the work of a threat hunting team like the one at Hard2bit Cybersecurity.
Patching, mitigation and containment
The main action is upgrading to TeamCity 2026.1.3 or 2025.11.7. For those who cannot do so immediately, JetBrains offers an interim security patch delivered as a plugin that covers versions 2017.1 and later; branches between 2017.1 and 2018.1 require a server restart after installation, while 2018.2 and later apply it without one. It is a temporary safety net, not a substitute for the upgrade.
Beyond the patch, a build server should not be exposed to the internet. Reducing its attack surface and segmenting it from the rest of the network limits who can even talk to the agent channel, while systems hardening and a least-privilege service account contain the damage if something gets in. These measures fit within a vulnerability management programme that prioritises by real exploitation, as the KEV, EPSS and SSVC frameworks propose, and a DevSecOps practice that treats the pipeline as a critical asset. It is the approach Hard2bit — operating since 2013, with its own ENS High-level and ISO 27001 certifications — takes to CI/CD exposure: prioritise by real exploitation and shrink what an attacker can reach.
If the server was exposed and unpatched during the exploitation window, prudence demands assuming compromise: rotate every credential, secret and signing key it held, review recent builds for tampering and trigger the incident response Hard2bit provides for compromised-account and compromised-server scenarios. With a build server, restoring the service is not enough; you have to write off whatever it held.
What to watch in the coming days
The immediate risk is not the flaw itself, which has a patch, but the number of TeamCity servers still running without it and still exposed. As exploitation broadens, those instances will be the target. And it is worth watching the underlying pattern: insecure deserialization in management and agent protocols recurs product after product, because the channel serving internal components tends to get less scrutiny than the user interface.
One fair question remains open: the details of in-the-wild activity are still taking shape, and attributions may change. The priority, though, is not in doubt: a server that builds software deserves the same protection as production, starting with not leaving it within reach of anyone who knows its address.
This article describes an actively exploited vulnerability using public sources available at the date of publication, for defensive purposes. It contains no exploit code or reproducible steps. The technical cause is explained conceptually, following the vendor's and third parties' analysis; versions, dates and recommendations should be verified against the official JetBrains and CISA advisories before acting.
