JetBrains disclosed CVE-2026-63077 on 27 July 2026. On 5 August, CISA added it to the Known Exploited Vulnerabilities catalogue, confirming exploitation in the wild.
CVSS 9.8. All versions of TeamCity On-Premises were affected. No credentials, no user interaction, low attack complexity — an attacker who can reach the server over HTTP executes operating system commands as the TeamCity server process.
The mechanism
This is CWE-502, deserialization of untrusted data, in about the most direct form the class takes.
TeamCity exposes an agent polling endpoint — the channel build agents use to check in with the server. Per Rapid7's analysis, an attacker sends a crafted payload to that endpoint, the server deserializes it, and gadget logic embedded in the object graph executes attacker-supplied instructions during reconstruction.
The important property of deserialization bugs, and the reason they keep producing 9.8s: the payload executes while it is being parsed. There is no point after deserialization at which the application can inspect the object and decide to reject it. By the time your code sees the result, the gadget chain has already run. Input validation placed after the deserialize call is decoration.
The second property is that the vulnerable surface is a legitimate protocol endpoint. The agent polling channel has to be reachable — that is how agents work. You cannot mitigate this by removing a feature nobody uses, because the feature is load-bearing.
Why a build server is the worst host to lose
Rank your infrastructure by what an attacker gets from full control of it, and CI/CD sits at or near the top. Not because the machine is valuable, but because of what it is trusted with.
A working TeamCity installation holds, by design:
- Deployment credentials for every environment it deploys to, production included
- Registry and artefact-store tokens with push rights
- VCS credentials with read access to every repository it builds, and often write
- Package registry publish tokens
- Signing keys, in organisations that sign artefacts
- Cloud provider credentials for provisioning build agents and deploying
- Source code for everything it builds, on disk
Compromise there is not lateral movement waiting to happen — it is a pre-assembled set of credentials to the systems that matter, plus the ability to modify what ships to production without touching a developer's machine or a repository.
That last capability is the one that should worry you most. An attacker with RCE on a build server can alter build output. The source in git is clean, the pull request review was legitimate, the commit signatures verify — and the artefact that reaches production contains something else. This is the shape of the most consequential supply chain attacks in the historical record, and it does not require compromising a single developer.
The pattern, not the instance
TeamCity has been through this before. CVE-2023-42793 was exploited by nation-state actors, and CVE-2024-27198 allowed authentication bypass and admin account creation. Three critical, remotely exploitable flaws in three years, in the same product.
This is not really a JetBrains story. It is what happens to any widely deployed, internet-reachable, credential-holding management application once attackers work out that it is worth the research investment. We made the same argument about the N-able N-central intrusion and Langflow's unauthenticated RCE last week. Management planes are where the credentials aggregate, so management planes are where the research goes.
The counterpart is maintainer account takeover, which reaches the same objective — control of what ships — with no vulnerability at all. Two routes, one destination.
What to do
Upgrade to TeamCity 2026.1.3 or 2025.11.7. If you cannot upgrade on that timeline, JetBrains ships a security patch plugin covering 2017.1 and later — genuinely useful for the long-lived installations that are hardest to move.
Take the server off the public internet. A TeamCity instance answering unauthenticated requests from anywhere is the precondition for exploitation. Agents can reach it over a private network or through a broker; the general internet does not need to.
Assume compromise if it was exposed and unpatched. Disclosure was 27 July and KEV listing 5 August. An instance reachable during that window on a vulnerable version should be treated as compromised, not as a patching task.
Rotate everything the server held, and do it in priority order: signing keys, deployment credentials, registry publish tokens, VCS credentials, cloud credentials. This is the expensive part and it is the part that actually matters.
Verify build output, not just the source. If the server was compromised, the question is whether artefacts were modified. Rebuild from a known-good environment and compare. Reproducible builds make this a real check rather than a hopeful one.
Audit for persistence. RCE as the server process means build configurations, plugins, and scheduled tasks could have been modified. Review the configuration, not only the process list.
The structural fix
The reason build-server compromise is catastrophic is that build servers hold standing, long-lived credentials to everything downstream. That is a design choice, and it is now an avoidable one.
OIDC and workload identity federation let a pipeline exchange a short-lived, workflow-scoped token for access at the moment it needs it, with nothing durable stored on the server. We covered this in the registry context when npm revoked all classic tokens, and the same reasoning applies to your cloud provider, your artefact store, and your deployment targets. Nobody is going to force that migration for you the way npm did.
An attacker with RCE on a build server that holds no resident credentials still has a serious incident. They do not have your production environment.
How Safeguard helps
CI/CD infrastructure in the same inventory as application dependencies. Safeguard's Supply Chain Core inventories build servers, appliances, containers, packages, models, and MCP servers into one continuous CycloneDX and SPDX record. The reason this CVE will sit unpatched in many estates is not difficulty — it is that nobody has a complete list of where TeamCity runs, including the instance a team stood up two years ago.
KEV-weighted prioritisation with asset context. A 9.8 with confirmed exploitation on the system that holds your deployment credentials is not the same as a 9.8 on an internal service. Safeguard ranks on KEV membership, exploit availability, EPSS, and what the affected asset can reach — the ordering we argued for in designing patch SLAs for 48-hour exploitation windows.
Build provenance and artefact integrity. Safeguard records what each build produced and from which inputs, so "were our artefacts modified during the exposure window" is answerable by comparison rather than by assumption. Against an attacker who can alter build output while leaving source intact, this is the only check that works.
Lion for the credential aggregation problem. Lion enforces just-in-time secret brokering so build environments hold no resident long-lived tokens, capability scoping so a compromised build step's reach is bounded, egress allowlists that break exfiltration, and signed audit trails that make the exposure window reconstructable. It is the operational form of the structural fix above.
Eagle and Griffin for the response. Eagle scopes which credentials were genuinely reachable from the compromised server so rotation is proportionate. Griffin authors and tests the credential-migration and version-bump changes across the affected repositories in parallel.
Check whether your build server answers a request from outside your network. That single fact determines whether this CVE is an upgrade ticket or an incident.
Sources: JetBrains security advisory · Rapid7 analysis · The Hacker News — CISA flags TeamCity CVE-2026-63077 · Help Net Security · CISA KEV Catalog
