Artificial Intelligence

TeamCity CVE-2026-63077 RCE: Patch Before KEV Deadline

August 13, 2026 · 5 min read · By CloudAI Security
TeamCity CVE-2026-63077 RCE: Patch Before KEV Deadline

JetBrains TeamCity CVE-2026-63077 is a critical unauthenticated remote code execution vulnerability that lets any attacker with HTTP(S) access bypass authentication and run arbitrary operating system commands. CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 5, 2026, giving organizations until August 8 to remediate. All on-premises versions are affected, while TeamCity Cloud customers face no action because the vendor already applied the fix.

CI/CD servers are high-value targets: they hold build credentials, secrets, and deploy tokens that an attacker can pivot through to reach production cloud infrastructure. A single compromised TeamCity instance can cascade into full kill-chain compromise, making rapid patching essential before threat actors weaponize public proof-of-concept code.

What CVE-2026-63077 Does

The vulnerability lives in TeamCity’s agent polling protocol — the channel that build agents use to register, receive commands, and report results. An attacker does not need credentials. They send a crafted XML payload to the unauthenticated /app/agents/v1/commands/error endpoint, and TeamCity’s deserialization logic executes embedded gadget-chain classes that ultimately write a webshell to the server’s web root. The result is full remote code execution with the privileges of the TeamCity server process, which often has access to source repositories, deployment keys, and connected cloud accounts.

JetBrains disclosed the flaw on July 27, 2026, after receiving a private report from researcher Antoni Tremblay on July 10, 2026. The vendor initially stated it was unaware of active exploitation, but a follow-up advisory confirmed that reports of active and attempted exploitation had begun targeting unpatched servers within days of disclosure.

Root Cause: XStream Permissions

TeamCity uses the XStream Java library to serialize and deserialize agent protocol messages. The vulnerable code creates an allowlist of permitted Java classes, but it adds those classes on top of XStream’s pre-existing default permissions rather than starting from a clean deny-by-default baseline. Those defaults broadly allow the Map and Throwable type hierarchies, which is enough to assemble a working deserialization gadget chain without ever naming a forbidden class explicitly.

The root cause is that a missing type-permission reset lets attackers smuggle dangerous classes through the allowlist. The exploit begins with HSQLMetadataStorage$SchemaMismatchException, a class that extends RuntimeException and is therefore accepted under the default Throwable permission. From there, declared fields guide XStream through BasicDataSource and into a FreeMarker-based gadget that writes a file to the web root, producing a JSP webshell that gives the attacker persistent command execution.

The patched versions fix this by calling NoTypePermission.NONE before populating the allowlist, which clears all default permissions and makes the TeamCity class list exclusive. This same pattern — an allowlist that silently inherits permissive library defaults — is a recurring trap in Java deserialization hardening and one that every cloud engineering team should audit across its toolchain. A similar CISA-deadline RCE pattern recently struck Microsoft SharePoint deployments, underscoring how fast active exploitation follows public disclosure.

How Attackers Exploit It

Exploitation requires only network reachability to the TeamCity server over HTTP or HTTPS. The attack proceeds in two steps: first, the attacker POSTs to /app/agents/v1/register to obtain a session identifier returned in the TeamCity-AgentSessionId response header, then sends a malicious XML body to the error-reporting endpoint using that same session header. No valid agent enrollment or user authentication is needed at any point in the chain.

Servers exposed to the internet are at immediate risk, but the blast radius extends to any environment where an attacker can traverse to the build server through a compromised developer workstation, a pivoted container, or a misconfigured cloud security group. Once code execution is achieved, the attacker can exfiltrate secrets stored in build configurations, poison artifacts, and establish persistence in downstream CI/CD pipelines that deploy to production.

Exposure scenarioRisk levelRecommended action
TeamCity login screen reachable from the public internetCriticalMove behind VPN or zero-trust proxy immediately; patch in parallel
Server reachable only from internal networkHighPatch to 2025.11.7 or 2026.1.3 within the KEV deadline
TeamCity Cloud managed serviceNoneNo action required — fix already applied by vendor
Legacy on-prem (2017.1 or newer), cannot upgradeHighInstall the security patch plugin as interim mitigation

Patch and Hardening Checklist

The following ordered procedure covers both immediate remediation and durable hardening for TeamCity deployments:

  1. Inventory all instances. Identify every TeamCity On-Premises server in your estate, including forgotten development and staging build servers that may be internet-exposed.
  2. Upgrade to 2025.11.7 or 2026.1.3. These versions include the fix for CVE-2026-63077. Use the in-product automatic update or download the installer directly from JetBrains.
  3. Apply the security patch plugin if upgrade is blocked. The plugin works on TeamCity 2017.1 and later, requires a server restart only on versions older than 2018.2, and addresses only this specific CVE — not other security improvements bundled in the full upgrade.
  4. Restrict network exposure. Require VPN or a zero-trust access proxy for any internet-facing TeamCity server. JetBrains itself recommends not exposing the login screen or REST API to untrusted networks.
  5. Audit build credentials. Rotate all secrets stored in TeamCity build configurations — API tokens, cloud deploy keys, and database passwords — because any exposed server must be treated as potentially compromised.
  6. Verify the patch. Confirm the teamcity.xstream.whiteList.forced internal property defaults to true on patched versions, which ensures XStream’s default permissions are cleared before the allowlist loads.

Teams that have already confirmed exposure should prioritize credential rotation and pipeline-integrity review over simple patching alone. A patched server that previously ran unauthenticated attacker code cannot be trusted without a full forensic sweep of build artifacts, container images, and deployed configurations.

Sources