CVE-2026-63077: JetBrains TeamCity Unauthenticated RCE in CISA KEV — Detection and Remediation Guide

On July 27, 2026, JetBrains published a security advisory for CVE-2026-63077, a critical unsafe deserialization vulnerability in TeamCity, its widely deployed continuous integration and build server. Rapid7's subsequent analysis confirmed what defenders feared: any attacker who can reach a TeamCity server over HTTP or HTTPS can abuse the agent polling protocol without credentials and execute operating system commands with the privileges of the TeamCity server process. On August 5, 2026, CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild.

If you run TeamCity, treat this as an incident, not a patch ticket. CI/CD servers hold source code, signing keys, deployment credentials, and pipeline secrets — a compromised build server is a supply-chain beachhead into everything your organization ships.

Why This Is Especially Dangerous

TeamCity sits at the center of the software factory. In most environments we assess, the TeamCity server process runs with broad privileges and has:

• Access to source control credentials and private repositories
• Stored artifacts, build outputs, and deployment packages
• API tokens and secrets injected into build configurations
• Network adjacency to artifact repositories, container registries, and production deployment targets

An unauthenticated RCE here is not a single-host compromise — it is a direct path to poisoning build outputs, harvesting credentials at scale, and pivoting into production infrastructure. The fact that exploitation requires no authentication and no user interaction means any TeamCity instance exposed to the internet, or reachable by an attacker with initial network foothold, is a target.

Technical Analysis

Affected Component

The vulnerability resides in TeamCity's agent polling protocol — the mechanism build agents use to communicate with the server. TeamCity servers listen for agent communication over the standard web interface (default HTTP port 8111, or HTTPS when TLS-terminated). Because the vulnerable code path is reachable over the same HTTP/HTTPS interface agents already use, perimeter filtering of agent traffic is not a reliable mitigation if agents legitimately poll from remote networks.

Root Cause: Unsafe Deserialization via XStream

Per Rapid7's analysis, a vulnerable TeamCity server instantiates a permissive XStream allowlist. XStream is a Java library that serializes objects to XML and back. The allowlist is intended to restrict which Java classes can be deserialized from incoming agent protocol messages — but the permissive configuration allows classes that should never be reconstructed from untrusted input.

The attack chain, from a defender's perspective:

1. Reconnaissance: Attacker identifies a reachable TeamCity server (port 8111 is a well-known fingerprint; the login page and agent protocol endpoints are distinctive).
2. Delivery: Attacker sends a crafted request to the agent polling protocol endpoint containing a malicious serialized object graph.
3. Deserialization: The server deserializes attacker-controlled class types permitted by the lax XStream allowlist.
4. Execution: A deserialization gadget chain in the server classpath converts object reconstruction into arbitrary OS command execution, running as the TeamCity service account (commonly SYSTEM on Windows or a dedicated teamcity user — but frequently root in poorly hardened Linux installs).

No credentials, session, or valid agent registration are required at any step.

Exploitation Status

• Confirmed in-the-wild exploitation — CISA KEV listing (August 5, 2026)
• Rapid7 published technical analysis of the root cause, which lowers the bar for additional actors to weaponize the flaw
• No known exploitation was reported by JetBrains at initial disclosure (July 27, 2026), but that window has closed

Federal civilian executive branch agencies are required to remediate KEV-listed vulnerabilities by the due date specified in the catalog under Binding Operational Directive 22-01. Every other organization should treat that deadline as its own.

Detection & Response

The highest-fidelity signal for this class of vulnerability is behavioral: the TeamCity server's Java process should never spawn shells, script interpreters, or system utilities as child processes. Everything below is built around that invariant, plus network-layer hunting for exploitation attempts against the agent protocol.

Sigma Rules

---
title: TeamCity Server Java Process Spawning Shell or Script Interpreter
id: 4c2a9f1e-7b3d-4e58-9a21-6f0c8d2b5a47
status: experimental
description: Detects the TeamCity server Java process spawning command shells or script interpreters, consistent with post-exploitation of CVE-2026-63077 unsafe deserialization RCE. The TeamCity server process should never legitimately spawn cmd.exe, powershell.exe, or similar children outside of defined build-agent activity on the server host itself.
references:
  - https://www.rapid7.com/blog/post/ra-unauthenticated-rce-in-jetbrains-teamcity-cve-2026-63077
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/08
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\java.exe'
    ParentCommandLine|contains:
      - 'TeamCity'
      - 'teamcity-server'
      - 'catalina'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\wmic.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\nltest.exe'
  condition: selection_parent and selection_child
falsepositives:
  - TeamCity build steps executing directly on the server host when a local agent is co-located with the server. Validate build logs before tuning.
level: critical
---
title: TeamCity Server Process Spawning Shell on Linux
id: 8e1d6c42-3a9b-4f07-b5e2-1d4c7a9f3e68
status: experimental
description: Detects the TeamCity server Java process spawning interactive shells or download utilities on Linux, consistent with command execution following exploitation of CVE-2026-63077.
references:
  - https://www.rapid7.com/blog/post/ra-unauthenticated-rce-in-jetbrains-teamcity-cve-2026-63077
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/08
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'TeamCity'
      - 'teamcity'
      - 'catalina'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
      - '/id'
      - '/whoami'
  condition: selection_parent and selection_child
falsepositives:
  - Build steps executing on a build agent co-located on the TeamCity server host. Correlate with build configuration logs.
level: critical
---
title: Suspicious HTTP Requests to TeamCity Agent Polling Endpoint
id: 2f7b3e91-5d48-4c16-a794-8e2b6d1c4a93
status: experimental
description: Detects HTTP POST requests to the TeamCity agent communication endpoint containing indicators of serialized Java object payloads, potentially representing CVE-2026-63077 exploitation attempts. Requires web/proxy logging upstream of the TeamCity server.
references:
  - https://www.rapid7.com/blog/post/ra-unauthenticated-rce-in-jetbrains-teamcity-cve-2026-63077
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/08
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/RPC2'
      - '/agentDetails.html'
      - '/app/agents/'
  selection_method:
    cs-method: 'POST'
  condition: selection_uri and selection_method
falsepositives:
  - Legitimate build agent polling. Baseline known agent source IPs and alert on requests from non-agent addresses; combine with payload size anomalies and deserialization gadget class names in request bodies where full capture is available.
level: high

Tuning note on rule 3: agent polling to /RPC2 is normal TeamCity behavior — the detection value comes from alerting on requests from source IPs that are not registered build agents. Implement the IP allowlist logic in your SIEM, not the Sigma rule itself.

KQL — Microsoft Sentinel / Defender

This query hunts for the TeamCity server process spawning unexpected children across Windows and Linux endpoints, and separately surfaces network connections to TeamCity's default listener from unexpected sources:

// Hunt 1: TeamCity server process spawning shells or tools (Windows + Linux via MDE)
let teamcity_parents = dynamic(["java.exe", "java"]);
let suspicious_children = dynamic([
  "cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe",
  "mshta.exe", "rundll32.exe", "wmic.exe", "certutil.exe", "bitsadmin.exe",
  "curl.exe", "whoami.exe", "net.exe", "sh", "bash", "dash", "curl", "wget",
  "nc", "ncat", "socat", "python", "python3", "perl", "base64", "id", "whoami"
]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (teamcity_parents)
| where InitiatingProcessCommandLine has_any ("TeamCity", "teamcity", "catalina")
| where FileName in~ (suspicious_children)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName, SHA256, ReportId
| order by TimeGenerated desc;

// Hunt 2: Inbound connections to TeamCity default port from non-agent sources
// Populate AgentIPs with your registered build agent addresses
let AgentIPs = dynamic(["10.0.1.0/24"]);  // replace with your agent subnet(s)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where LocalPort == 8111 and ActionType == "InboundConnectionAccepted"
| where not(ipv4_is_in_range(RemoteIP, tostring(AgentIPs[0])))
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, RemoteIP, RemotePort
| order by ConnectionCount desc;

// Hunt 3: Syslog-ingested TeamCity hosts — shell execution under teamcity user
Syslog
| where TimeGenerated > ago(14d)
| where HostIP has "teamcity" or Computer has "teamcity"  // adjust to your naming convention
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "wget", "curl", "base64 -d")
| project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL

Use this artifact to sweep your fleet for TeamCity server processes and enumerate their children and network listeners — useful both for identifying vulnerable instances you didn't know you had (shadow CI is real) and for triaging suspected compromise:

-- Identify TeamCity server processes, their children, and listeners
SELECT Pid,
       Ppid,
       Name,
       CommandLine,
       Exe,
       Username,
       CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)teamcity|catalina'
   OR Name =~ '(?i)teamcity'

-- Enumerate listeners on TeamCity default ports to find exposed instances
SELECT Pid,
       Name,
       LocalAddress,
       LocalPort,
       RemoteAddress,
       RemotePort,
       Status
FROM netstat()
WHERE LocalPort in (8111, 9090)
   OR RemotePort in (8111, 9090)

If either query returns a TeamCity server process with child processes that are shells or download utilities, isolate the host immediately and begin IR scoping — do not wait for additional confirmation.

Bash Verification & Hardening Script

Run this on Linux TeamCity servers to confirm the installed version, enumerate recent suspicious child processes of the TeamCity JVM, and check for unexpected listeners:

#!/bin/bash
# CVE-2026-63077 - TeamCity triage and verification script
# Run as root on the TeamCity server host

echo "=== [1] Installed TeamCity version ==="
if [ -f /opt/TeamCity/webapps/ROOT/WEB-INF/lib/server.jar ]; then
  echo "TeamCity installation found at /opt/TeamCity"
fi
# Query the server's own REST API for build number (adjust port/host as needed)
curl -sk http://localhost:8111/app/rest/server/version 2>/dev/null || echo "REST API not reachable on localhost:8111"

echo ""
echo "=== [2] TeamCity server process and recent child processes ==="
TC_PID=$(pgrep -f "teamcity" | head -n 1)
if [ -n "$TC_PID" ]; then
  echo "TeamCity server PID: $TC_PID"
  echo "--- Full process tree under TeamCity JVM ---"
  pstree -p "$TC_PID"
  echo ""
  echo "--- Suspicious descendants (shells/tools) ---"
  ps --ppid "$TC_PID" -o pid,ppid,user,cmd 2>/dev/null
else
  echo "No TeamCity process found by pgrep; verify with: ps aux | grep -i catalina"
fi

echo ""
echo "=== [3] Listening ports (expect 8111/HTTPS; flag anything unexpected) ==="
ss -tlnp | grep -E '8111|9090|8443'

echo ""
echo "=== [4] Recent outbound connections from TeamCity process ==="
if [ -n "$TC_PID" ]; then
  ss -tnp | grep "pid=$TC_PID" || echo "No active outbound connections from TeamCity PID"
fi

echo ""
echo "=== [5] Auth/access log review pointers ==="
echo "Review TeamCity access logs for POST /RPC2 from non-agent source IPs:"
echo "  grep -h 'POST /RPC2' /opt/TeamCity/logs/catalina*.log | awk '{print \$1}' | sort | uniq -c | sort -rn | head -20"
echo ""
echo "ACTION REQUIRED: Apply the JetBrains fixed build per the official advisory BEFORE returning this host to service."

Remediation

1. Patch immediately. Apply the fixed TeamCity build specified in JetBrains' official security advisory for CVE-2026-63077. JetBrains publishes fixed versions and upgrade instructions at https://www.jetbrains.com/teamcity/ and through its security advisories page. Verify the exact fixed build number against the advisory — do not assume your installed version is patched simply because auto-update notifications are enabled.

2. If you cannot patch today, remove network exposure. Take the server off any internet-facing path and restrict access to port 8111 (or your configured port) to only the networks that absolutely require it: administrators and registered build agents. This is a temporary compensating control, not a fix — an attacker with any internal foothold can still exploit it.

3. Restrict agent protocol reachability. Implement source-IP allowlisting for agent polling traffic so only known, registered build agents can reach the agent communication endpoints. Rapid7's analysis confirms the vulnerable code path is reachable via the agent polling protocol — cutting off unauthenticated network paths to it reduces attack surface materially.

4. Hunt before you patch. Because exploitation is confirmed in the wild, patching alone is insufficient — a patched server may already be compromised. Run the process-tree and network hunts above covering at least the window from July 27, 2026 (disclosure) forward. Look specifically for the TeamCity JVM spawning shells, new local users, unexpected outbound connections, dropped files in temp directories, and modified build configurations.

5. Rotate everything the server could touch on suspicion of compromise. If triage turns up any positive indicator, treat all secrets reachable from the TeamCity server as burned: VCS tokens, deployment credentials, artifact registry keys, signing certificates, and any pipeline-injected secrets. Reset service account passwords and review build artifacts produced during the exposure window for tampering.

6. Meet the CISA KEV deadline. Federal agencies must remediate per the due date in the KEV catalog under BOD 22-01. Private-sector organizations should adopt the same date as their internal SLA — CISA sets those deadlines based on observed exploitation tempo.

7. Longer-term hardening. Run the TeamCity service under a least-privilege dedicated account (never root/SYSTEM), segment the CI/CD network from production and corporate user networks, put an authenticating reverse proxy with TLS in front of the server, and forward TeamCity server and access logs to your SIEM permanently — this is the third major TeamCity security event pattern we've seen in recent years, and it will not be the last.

The Bigger Picture

CI/CD infrastructure has become the soft underbelly of enterprise security. Build servers are internet-reachable by design in many organizations, run with standing access to the crown jewels of the software supply chain, and are frequently excluded from the hardening and monitoring rigor applied to other production systems. CVE-2026-63077 — unauthenticated, network-reachable, actively exploited — is exactly the threat model that justifies treating your build pipeline as tier-zero infrastructure. Patch now, hunt aggressively, and assume exposure until proven otherwise.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub