CVE-2026-63077

What is JetBrains TeamCity?

TeamCity is JetBrains' continuous integration and delivery server. A TeamCity installation orchestrates builds across a fleet of remote build agents, stores source-control credentials, deployment keys, signing certificates, and cloud provider tokens, and typically has push access to production infrastructure.

That makes a TeamCity server one of the highest-value targets in an enterprise network. Compromising it is rarely the end goal — it is a staging point for supply-chain tampering and for harvesting the credentials that reach everything the CI system can deploy to. TeamCity has a track record here: CVE-2024-27198 and CVE-2023-42793 were both mass-exploited authentication bypasses, the latter by APT29 (SVR) and by North Korean actors deploying ransomware.

Overview

CVE-2026-63077 is an unauthenticated remote code execution vulnerability in TeamCity On-Premises, scored CVSS 9.8. An attacker who can reach the TeamCity web port can self-register as a build agent, send a crafted XML document to the agent error-reporting endpoint, and have it deserialized into a gadget chain that writes and executes a JSP web shell.

There is no meaningful authentication barrier. The "session" the endpoint checks is one the attacker mints for themselves in a preceding request.

JetBrains patched it on 2026-07-27 after a coordinated private report. CISA added it to the KEV catalog on 2026-08-05 with a three-day BOD 26-04 remediation deadline of 2026-08-08.

Affected Versions

TeamCity 2024.03 and later notify administrators in the UI when a security patch plugin is available.

Technical Details

Root cause — an additive XStream allowlist. TeamCity's XStreamHolder calls xStream.allowTypes() to whitelist the classes it expects to deserialize, but never calls NoTypePermission.NONE first. Without that clearing call the allowlist is additive on top of XStream's permissive defaults, which still admit broad hierarchies such as Map and Throwable. The intended deny-by-default posture never takes effect. The patch is essentially one line: clear the permissions before adding to them.

Reaching the sink. The vulnerable entry point is POST /app/agents/v1/commands/error, part of the agent polling protocol. It accepts an XML body and routes it through Error.fromXml() → XStreamWrapper.deserializeObject().

Getting a valid session is trivial: /app/agents/v1/register lets any client register itself as a build agent and receive a TeamCity-AgentSessionId. The error handler confirms the session exists but never verifies the caller owns the agent it belongs to. Registration is self-service, so the endpoint is unauthenticated in every sense that matters.

Gadget chain. Per Rapid7's analysis, the payload is a LinkedHashMap with three entries:

1. An HSQLMetadataStorage$SchemaMismatchException, admitted by the default Throwable permission. Its synthetic outer-class field references an HSQLStorage holding an Apache Commons DBCP BasicDataSource configured with the HSQLDB driver and attacker-controlled connection-initialization SQL.
2. A FreeMarker HashAdapter wrapping a BooleanModel, which exposes JavaBean property resolution over that datasource.
3. A TiedMapEntry inside a HashSet. Insertion into the set calls hashCode(), which calls map.get("connection"), which FreeMarker resolves as a bean property — invoking BasicDataSource.getConnection().

From SQL to shell. Opening the connection starts an in-memory HSQLDB instance and runs the attacker's init SQL. That SQL creates a table whose contents are a JSP scriptlet, then uses HSQLDB's SCRIPT command to dump it to webapps/ROOT/<random>.jspws. Requesting that file maps it to the Jasper JSP servlet — which sidesteps TeamCity's JspController authentication — compiling and executing Runtime.getRuntime().exec() as the TeamCity server process.

Attack characteristics. Unauthenticated, no user interaction, network-reachable over HTTP/HTTPS. Multiple requests, but all attacker-driven with no victim participation and no prerequisite access. Not chained with any other CVE.

Discovery

Reported privately to JetBrains by researcher Antoni Tremblay on 2026-07-10 through coordinated disclosure. The advisory and fixed builds shipped on 2026-07-27. It was not a zero-day at the time of disclosure — exploitation began after the patch, following public technical analysis.

Exploitation Context

CISA confirmed active exploitation when it added the CVE on 2026-08-05, but published no supporting detail — no threat actor, no campaign, no technique. SecurityWeek and The Hacker News both noted the absence. No Shodan, Censys, or Shadowserver exposure figures have been published for this CVE.

What is clear is that weaponization is straightforward. Rapid7 published a complete root-cause analysis including the working gadget chain, and the patch is a one-line diff that points directly at the flaw. The gap between "patch released" and "exploit reproduced from the diff" was days.

The strategic context matters more than the raw volume. Historically, TeamCity mass-exploitation has been followed by supply-chain tampering and credential theft rather than smash-and-grab activity — CVE-2023-42793 drew both APT29 and DPRK-linked ransomware operators. Any TeamCity server that was internet-reachable and unpatched between 2026-07-27 and the KEV deadline should be treated as potentially compromised, not merely as needing an upgrade.

Remediation

1. Upgrade immediately to TeamCity 2026.1.3 or 2025.11.7.
2. If upgrading is not possible, install the security patch plugin (fix_CVE_2026_63077.zip), which JetBrains provides for 2017.1 and later. This is a stopgap, not a substitute for upgrading.
3. Remove the server from direct internet exposure. JetBrains recommends placing internet-facing TeamCity servers behind a VPN. The agent polling endpoints in particular have no business being publicly reachable.
4. Assume credential compromise if the server was exposed. Rotate every VCS credential, deployment key, API token, cloud provider credential, and signing key that TeamCity stores or can reach. Patching does not evict an attacker who already has your CI secrets.
5. Hunt for the web shell. Audit webapps/ROOT/ for unexpected .jspws or .jsp files and for files with recent creation timestamps. Review access logs for requests to /app/agents/v1/register and /app/agents/v1/commands/error from unfamiliar source addresses, and for subsequent requests to randomly-named files at the web root.
6. Reduce blast radius. Run TeamCity as a low-privilege OS account on a dedicated host, so that RCE in the server process does not immediately mean full host and network compromise.
7. Review build history for unexpected build configuration changes, new build steps, or altered artifacts in the exposure window.