CVE-2026-63077: When TeamCity Deserializes Trust

POST /agent/poll returns 200. A moment later, the build server writes a file nobody asked it to create.

That sequence is hypothetical, not a reconstruction of a real intrusion. The uncomfortable part is the decision an operator makes next. The login page is irrelevant. The request did not carry a session. If a protocol intended for trusted build agents can reach object reconstruction before identity is established, the attacker is no longer trying to authenticate. They are testing whether the server will turn their data into behavior.

On July 27, 2026, JetBrains disclosed CVE-2026-63077, a critical unauthenticated remote code execution vulnerability in every version of TeamCity On-Premises. An attacker with HTTP(S) reachability can abuse the agent polling protocol, bypass authentication checks, and execute operating system commands with the privileges of the TeamCity server process. JetBrains fixed the flaw in 2025.11.7 and 2026.1.3, and released a security patch plugin for versions 2017.1 and later.

The CVE maps to CWE-502, deserialization of untrusted data. The CVSS 3.1 score is 9.8, also recorded in Rapid7’s July 29 analysis. At disclosure, JetBrains said it was not aware of active exploitation. Those are the confirmed facts. The vendor did not publish the request syntax, affected classes, gadget chain, or exact parser path. Any article claiming those details without new evidence is filling gaps with fiction.

The trust boundary is in the wrong place

A CI server has at least two personalities. To users, it is a web application with accounts, roles, projects, and an administrative interface. To build agents, it is a coordinator speaking machine protocol: poll, assign work, transfer configuration, report status, repeat.

An operator looking for the shortest path does not begin with the feature list. They ask three narrower questions:

• Which machine-facing routes are reachable on the same HTTP(S) listener as the login page?
• Which of those routes must parse input before the peer is fully trusted?
• What authority belongs to the process that performs the parsing?

CVE-2026-63077 collapses those questions into one dangerous chain. Network reachability reaches the agent polling protocol. Unauthenticated input reaches an unsafe deserialization boundary. The resulting behavior runs inside the TeamCity server process. That process often sits near repository credentials, build secrets, signing material, package registries, deployment tokens, and artifacts trusted by other systems.

This is why “RCE on a server” understates the impact. The first compromised host is the control plane of a software factory. The blast radius is shaped less by local files than by every identity and release path the server can exercise. The same reasoning appears in our guide to identities, trust boundaries, and attack chains: the vulnerable process matters, but its outbound capabilities determine the operation.

What deserialization changes

Serialization converts state into bytes. Deserialization rebuilds it. Safe designs treat the wire format as data, validate a small schema, and create new application objects from accepted fields. Unsafe designs allow the input to influence types, constructors, callbacks, or object graphs with behavior during reconstruction.

The attacker does not need to upload a conventional executable if the runtime already contains useful behavior. They look for a sequence of available methods, often called a gadget chain, that turns reconstruction into an unintended action. The final effect could be a file write, a process launch, a network request, a state change, or denial of service. Which chain applies depends on the language, libraries, classpath, and vulnerable code path. None of those product-specific mechanics were disclosed for CVE-2026-63077.

The critical architectural mistake is temporal: authentication is evaluated after dangerous interpretation, or it protects the user-facing route while a machine route performs equivalent work under weaker assumptions. This resembles the route and parser confusion behind wp2shell. The products and bugs differ, but the review question is the same: which parser runs before the security decision, and what authority does it inherit?

A safe mechanism lab, not a TeamCity exploit

The following lab does not contain TeamCity code, does not reproduce its protocol, and is not a CVE-2026-63077 proof of concept. It isolates the disclosed weakness class on 127.0.0.1. The payload performs one harmless action: it writes LAB_ONLY_EXECUTION into a temporary directory that the verifier deletes.

The vulnerable handler interprets a native serialized object directly. The fixed handler accepts JSON, compares it with a strict schema, and never asks the runtime to reconstruct attacker-selected behavior.

# Vulnerable mechanism
body = request.read(content_length)
pickle.loads(body)  # object reconstruction can invoke behavior

# Fixed mechanism
obj = json.loads(body)
if obj != {"type": "poll", "agent": "lab-agent-01"}:
    raise ValueError("schema rejected")
# Map validated fields into application state. Do not rebuild native objects.

I executed the complete verifier locally on loopback. It started a bounded HTTP server for each mode, sent the same serialized payload, checked the marker, tested one valid JSON poll, stopped both servers, and removed the fixture directory.

$ python3 deserialization_mechanism_lab.py
VULNERABLE_HTTP_STATUS=200
VULNERABLE_CODE_EXECUTION=True
FIXED_MALICIOUS_HTTP_STATUS=400
FIXED_CODE_EXECUTION=False
FIXED_VALID_POLL_HTTP_STATUS=202

The lesson is not “JSON is automatically safe.” A JSON parser can still feed command injection, template injection, or unsafe reflection. The defensive property is narrower: untrusted bytes are decoded into inert values, checked against an allowlist, and mapped into newly created state without attacker-selected types or reconstruction hooks.

A realistic attack chain

Consider an internet-reachable TeamCity deployment. This chain is an analytical model based on the vendor-confirmed impact and normal CI/CD authority, not a claim that exploitation has occurred.

1. Reachability and version triage

The operator identifies a TeamCity listener and tests only enough behavior to distinguish the product and exposure. The important observation is not whether login is strong. It is whether agent-facing traffic shares the reachable HTTP(S) surface. JetBrains explicitly states that servers reachable over HTTP(S) are exposed to the vulnerable path.

2. Protocol input reaches object reconstruction

A crafted message enters the agent polling protocol without valid user credentials. According to JetBrains, this path can bypass authentication checks and reach command execution. The CVE record identifies CWE-502. The undisclosed portion is how the object graph crosses that boundary and which gadget completes the chain.

3. Execution inherits the server identity

The first useful discovery is process context: operating system account, filesystem access, environment, outbound network paths, and readable TeamCity configuration. A low-privilege dedicated account contains this step. A service running with broad host rights turns it into immediate host control.

4. CI authority becomes the objective

An efficient attacker does not linger on the server if the build plane offers better leverage. They enumerate repository credentials, artifact registries, cloud deployment identities, signing workflows, and project-level secrets. They also study which output is trusted without independent provenance checks. The objective shifts from owning TeamCity to making downstream systems accept attacker-influenced output.

5. Artifact tampering or quiet credential use

Two branches follow. A loud operation modifies builds or artifacts. A quieter one steals a credential and moves elsewhere, leaving the CI server as initial access rather than the final operating base. Defenders who patch and stop there can miss both. The integrity question is retrospective: which builds, releases, tokens, and deployment actions were touched during the exposure window?

That concern is not theoretical in the general TeamCity threat model. In December 2023, a joint CISA, FBI, NSA, SKW, CERT Polska, and NCSC advisory documented Russian SVR exploitation of a different TeamCity flaw, CVE-2023-42793. The agencies warned that TeamCity access can expose source code, signing certificates, build pipelines, and opportunities to tamper with software. This history does not prove exploitation of CVE-2026-63077. It proves that attackers understand the strategic value of the product.

Detection without invented indicators

There is no defensible CVE-specific URI, payload signature, or gadget indicator in the public primary material reviewed for this article. Detection should therefore combine the known surface with behavioral evidence, while teams obtain any vendor or EDR-specific content available to them.

• HTTP telemetry: retain reverse-proxy and TeamCity access logs. Baseline agent polling volume, source networks, methods, content types, body sizes, error rates, and bursts from addresses that are not approved build agents. Do not hard-code an endpoint name copied from an unverified exploit post.
• Process telemetry: alert when the TeamCity server process creates command interpreters, download tools, script engines, archive utilities, or unexpected child processes. Tune for legitimate plugins and administrative tasks, but treat new parent-child relationships as high priority.
• Credential access: monitor reads of TeamCity configuration, token stores, SSH material, signing keys, and cloud credential paths by unusual processes or at unusual times.
• Build integrity: compare build configuration changes, plugin installation, agent authorization, artifact hashes, signing events, and deployment records against approved change windows.
• Egress: flag new destinations from the TeamCity server. Build infrastructure often has broad outbound access, so identity-aware allowlists are more useful than a generic “internet permitted” rule.

# Behavioral analytic, adapt field names to your EDR
selection:
  parent_process|contains: 'teamcity'
  child_process|endswith:
    - '/sh'
    - '/bash'
    - '/curl'
    - '/wget'
    - '\\cmd.exe'
    - '\\powershell.exe'
condition: selection
triage:
  - correlate with inbound HTTP activity
  - inspect service account and command line
  - compare with approved plugin or maintenance activity

This analytic is intentionally generic. It is a hunting starting point, not a CVE signature. A TeamCity process can launch tools during legitimate maintenance, and an attacker can execute through less obvious primitives. Parent-child telemetry must be joined with network, file, identity, and build evidence.

Patch first, then prove the pipeline

JetBrains provides two remediation paths. Upgrade to TeamCity 2025.11.7 or 2026.1.3. If an immediate upgrade is impossible, install the vendor security patch plugin on TeamCity 2017.1 or later. The plugin fixes only CVE-2026-63077, so it is a bridge, not a replacement for a supported release. TeamCity Cloud customers do not need to act because JetBrains applied the protection.

Then address the conditions that turn one parser bug into supply-chain control. JetBrains maintains a separate TeamCity server security guide covering network exposure, service isolation, agents, secrets, and operating system privileges.

1. Remove direct internet exposure. Require VPN or another access layer, and allow only administrators and approved agents to reach the service.
2. Run the TeamCity server with minimum operating system privileges on a dedicated host, separate from build agents, as JetBrains recommends.
3. Reduce credential lifetime and scope. Prefer short-lived workload identities over reusable cloud keys and static deployment tokens.
4. Separate build from release authority. A compromised build coordinator should not be able to produce and promote a trusted release without an independent policy decision.
5. Verify provenance and signatures outside the compromised trust domain. An approval dialog or successful build is not proof of the object actually modified, a lesson also visible in GhostApproval.
6. If exposure existed before remediation, preserve logs, isolate the server, rotate reachable credentials, review plugins and configuration, rebuild from known-good media, and validate artifacts produced during the suspect window.

Strategic takeaways

CVE-2026-63077 is urgent because three boundaries fail in sequence: public network access reaches a machine protocol, untrusted bytes reach object reconstruction, and reconstructed behavior inherits CI/CD authority. Fixing the parser closes the disclosed vulnerability. Fixing the architecture limits the next one.

For offensive teams, the productive question is not “can I reach the login page?” It is “which pre-authentication machine channels perform rich parsing, and what identities sit behind them?” For defenders, the corresponding question is whether compromise of the CI coordinator can silently become trusted software.

The smallest detail in the advisory is the most useful one: agent polling protocol. It identifies a trust relationship that deserves inventory, isolation, logging, and hostile-input review. Patch the known flaw now. Keep the protocol boundary under suspicion after the emergency is over.