CVE-2026-63077 Puts Unauthenticated RCE on Every TeamCity On-Premises Server

JetBrains TeamCity On-Premises ships a critical remote code execution flaw under CVE-2026-63077. The bug lives in the agent polling protocol: an unauthenticated attacker sends crafted data that the server deserializes, yielding code execution with TeamCity server privileges. CVSS 9.8 is the score; the blast radius is whatever your build system touches — source repositories, cloud deployment keys, signing material, and the artefacts those pipelines produce.

JetBrains published the advisory on 27 July 2026 and stated it had no evidence of exploitation at disclosure. That changed quickly. CISA added CVE-2026-63077 to the Known Exploited Vulnerabilities catalog on 5 August, setting a federal remediation deadline of 8 August — three days. Fixed releases are TeamCity 2025.11.7 and 2026.1.3. Older supported versions can apply JetBrains' security patch plugin back to 2017.1. TeamCity Cloud is not affected.

The gap between "no known exploitation" at disclosure and KEV listing eight days later is the signal. Scanner coverage and proof-of-concept research catch up fast on deserialization bugs in widely deployed CI/CD products. If your TeamCity server has a DNS record or accepts agent connections from anything other than a tightly controlled build network, assume it is on someone's target list regardless of what the initial advisory said.

How Agent Polling Becomes RCE

TeamCity agents poll the server for commands. That polling channel is designed for high-frequency, machine-to-machine traffic — exactly the sort of path that sometimes receives less authentication scrutiny than the web UI administrators log into daily.

CVE-2026-63077 is a deserialization of untrusted data flaw in that protocol handling. The attacker does not need a user account on TeamCity. They need network reachability to the server and the ability to send malformed polling payloads the server will parse.

Successful exploitation typically proceeds through:

• Delivery of a crafted polling message that triggers unsafe deserialization on the server.
• Code execution in the TeamCity server process context, which runs with access to the application's database, configuration store, and credential vault.
• Credential harvesting and pipeline modification as follow-on objectives rather than as separate vulnerabilities.

Because the entry point is unauthenticated, exposure assessments that only reviewed who can log into the web interface miss the attack path entirely.

Why CI/CD Compromise Is a Supply-Chain Event

A TeamCity server is not "just another internal app." It holds the keys that let automation reach production.

After server-level RCE, attackers routinely pursue:

• Stored credentials for Git hosting, artifact repositories, container registries, and cloud APIs — often scoped broadly because build jobs need them.
• Build configuration changes that add a malicious step to an existing pipeline, similar in effect to compromised GitHub Actions workflows but centred on self-hosted infrastructure many security teams inventory poorly.
• Artifact tampering — replacing a built package or container image before it reaches downstream consumers who trust the CI system's output signature.
• Persistence through build triggers and agent hooks that survive a simple server restart until someone diffs pipeline definitions against a known-good baseline.

The parallel to GitHub Actions supply-chain themes is deliberate. Hosted CI providers publish hardening guides because pipeline secrets are high-value targets. Self-hosted TeamCity behind a corporate firewall received the same trust model without always receiving the same network controls — and CVE-2026-63077 removes the comfort of "they need credentials first."

Patch Paths and the Security Plugin

JetBrains offers two remediation routes:

• Upgrade to 2025.11.7 or 2026.1.3 on the main supported lines — the preferred fix for teams that can move release trains quickly.
• Apply the security patch plugin on older 2017.1+ installations that cannot jump versions immediately.

The plugin is a bridge for maintenance windows measured in weeks, not an excuse to defer indefinitely. Deserialization flaws in polling protocols tend to attract public exploit research once KEV listing confirms operational urgency. Teams on 2019.x or 2022.x branches should schedule the mainline upgrade alongside plugin deployment rather than treating the plugin as permanent state.

Document which agents connect from which subnets before patching. A rushed upgrade that drops agent connectivity looks like an outage; a rushed upgrade without log preservation loses the evidence you need if exploitation predates the fix.

CISA KEV and the Three-Day Federal Clock

KEV inclusion on 5 August with remediation due 8 August tells federal agencies — and everyone else reading the catalog — that CISA expects active or imminent exploitation even though JetBrains had none to cite at disclosure.

Private-sector teams should interpret the timeline as:

• Patch or isolate exposed TeamCity servers before the end of the week the KEV entry landed, not at the next quarterly maintenance cycle.
• Assume scanning started once the CVE identifier circulated in vendor feeds and security mailing lists, even before a public PoC.
• Treat agent polling ports with the same firewall discipline as the web UI and REST API.

Track the CVE in CVE Watch alongside EPSS movement so reprioritisation happens when the score shifts, not when an incident forces it.

Detection and Hunting Signals

Work from logs and network data you already collect:

• Deserialization or parsing errors in TeamCity server logs on the agent polling endpoint, especially if clustered around a single source address.
• New agent registrations or agent UUIDs that do not map to known build hosts.
• Unexpected process execution on the TeamCity server host outside scheduled maintenance — Java child processes spawning shells are never normal on a build coordinator.
• Outbound connections from the server to paste sites, VPS networks, or Tor-adjacent hosting — post-exploitation staging often egresses directly from the compromised host before lateral movement.
• Pipeline definition changes timestamped around the same window as polling anomalies, including new script steps, modified dependencies, or added deployment targets.

If TeamCity sits in a developer VLAN with flat routing, hunt downstream as well. Build servers are pivot points. An attacker who lands server RCE often uses stored cloud keys within minutes.

Network Controls and Enrichment

Minimum posture while patching:

• Restrict agent polling and web UI access to build-network subnets only. If developers need the UI from laptops, put it behind VPN or zero-trust access rather than a public DNS name "temporarily" left up since a proof of concept.
• Segment TeamCity from production even if pipelines deploy there — the server should initiate outbound deployment connections; production workloads should not initiate inbound management sessions to the build tier.
• Review stored credentials and rotate any secret the TeamCity vault could expose after suspected contact with malicious polling traffic.

When hunting produces unfamiliar source IP addresses, enrich before closing the ticket:

• IP reputation lookups for addresses hitting polling endpoints from outside your build network.
• Bulk lookups when reviewing weeks of logs — deserialization probes often come as short bursts from many hosts.
• Feed enrichment into your SIEM via the API so the next TeamCity alert includes hosting context and prior malicious association automatically.

For domains seen in modified pipeline steps or callback URLs, use domain intelligence and DNS history.

Incident Response When Exploitation Is Suspected

If enrichment links polling traffic to known exploit infrastructure or pipeline diffs show unauthorised changes, run incident response as a supply-chain case:

• Preserve TeamCity database and server logs before retention expires.
• Diff all build configurations and deployment scripts against last-known-good from source control, not from the TeamCity UI alone — an attacker with server access can hide changes in the UI view you are using to investigate.
• Rotate every credential in the TeamCity credential store and any secret a compromised pipeline could reach downstream.
• Review artefacts built during the exposure window for signs of tampering before redeploying them.

Wire vulnerability management tracking so CVE-2026-63077 stays tied to the specific TeamCity hosts in scope until each reports a fixed version — KEV closure in a spreadsheet is not the same as closure on the server.

TeamCity Cloud customers can stand down on server patching. Everyone else should treat CVE-2026-63077 as a perimeter-class flaw on infrastructure that signs software the organisation actually runs. Patch, restrict, hunt egress, enrich the hits — the three-day federal deadline is a useful reminder that CI/CD servers are no longer "internal only" in anyone's threat model.