CISA has added CVE-2026-63077 to its Known Exploited Vulnerabilities (KEV) catalog, confirming what many of us in incident response have been bracing for: attackers are actively exploiting a critical flaw in on-premise JetBrains TeamCity servers in the wild. This is a CVSS 9.8 deserialization-of-untrusted-data vulnerability that allows an unauthenticated attacker with network access to a TeamCity server to achieve remote code execution.
If you operate CI/CD infrastructure, this is a five-alarm fire. Build servers are among the highest-value targets in any enterprise environment — they hold source code, signing keys, deployment credentials, cloud tokens, and pipeline secrets. A compromised TeamCity server is not just a single host breach; it is a supply-chain beachhead that lets an adversary poison every build artifact that flows through your pipeline. JetBrains TeamCity vulnerabilities have been a favorite of both ransomware operators and nation-state actors precisely for this reason.
If your TeamCity instance is reachable from the internet, or from any network segment an attacker can reach, treat this as an incident, not a patch ticket.
Technical Analysis
What is CVE-2026-63077?
CVE-2026-63077 is a case of CWE-502: Deserialization of Untrusted Data affecting on-premise versions of JetBrains TeamCity. The flaw carries a CVSS v3.1 score of 9.8 (Critical) — consistent with a remotely exploitable, unauthenticated vulnerability requiring no user interaction.
From a defender's perspective, the mechanics matter:
- Affected component: The TeamCity server application (Java-based). Deserialization flaws in Java applications typically arise when attacker-controlled serialized objects are accepted by an exposed endpoint and passed to a vulnerable deserializer without type filtering or allow-listing.
- Attack preconditions: Network access to the TeamCity server web interface (default HTTP port 8111). No authentication, no credentials, no valid session required. This is what makes the flaw so dangerous — any system or adversary that can reach the port can attempt exploitation.
- Impact: Arbitrary code execution in the context of the TeamCity server service account. On Windows installations this is frequently
NT AUTHORITY\SYSTEMor a dedicated service account; on Linux, theteamcityuser orrootif the service was misconfigured. Post-exploitation, attackers gain access to everything the build server can reach: VCS credentials, artifact repositories, deployment targets, and stored secrets.
Exploitation Status
- Active exploitation in the wild: CONFIRMED by CISA.
- KEV listed: Yes. Federal Civilian Executive Branch (FCEB) agencies are mandated to remediate under BOD 22-01 within the KEV due-date window (typically three weeks from catalog addition). Every private-sector organization should treat that same deadline as its own.
- Attack surface reality: TeamCity servers are routinely exposed to the internet — intentionally (for distributed teams and remote build agents) and unintentionally (flat networks, misconfigured reverse proxies, forgotten test instances). Shodan and Censys consistently index thousands of reachable TeamCity instances, and scanners began probing for this class of endpoint almost immediately after patch availability.
Why Build Servers Are the Target
In our IR engagements, CI/CD compromise consistently follows a predictable playbook after initial code execution:
- Credential harvesting — dumping stored VCS tokens, SSH keys, cloud provider credentials, and service account secrets from TeamCity's configuration and environment variables.
- Pipeline tampering — injecting malicious build steps or modifying build configurations so every subsequent artifact ships with an implant.
- Lateral movement — using the build server's trusted network position (it can push to production) to reach deployment targets.
- Persistence — webshells dropped into the TeamCity web application directory, rogue local accounts, or malicious build configurations that survive service restarts.
Detection content below is built around this observed behavioral chain, not just the initial exploit.
Detection & Response
The initial deserialization exploit itself is difficult to signature reliably at the network layer without vendor IoCs. What defenders can reliably detect is the post-exploitation behavior: the TeamCity Java process spawning shells and tools it should never spawn, and outbound connections from a server that should only be talking to build agents and artifact repos.
Sigma Rules
---
title: TeamCity Server Process Spawning Shell or Script Interpreter
id: 9f2e6b41-3c7d-4a1e-b8f2-6d4c9a1e5f07
status: experimental
description: Detects the TeamCity server Java process spawning command shells, script interpreters, or living-off-the-land binaries — a strong indicator of post-exploitation following RCE such as CVE-2026-63077.
references:
- https://thehackernews.com/2026/08/cisa-flags-teamcity-cve-2026-63077-rce.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/15
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\java.exe'
- '\javaw.exe'
- '\TeamCityService.exe'
- '\teamcity-server.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\wget.exe'
- '\net.exe'
- '\net1.exe'
- '\whoami.exe'
condition: selection_parent and selection_child
falsepositives:
- Build configurations legitimately invoking cmd/powershell run under build AGENT processes (teamcity-agent), not the server process. Validate parentage before tuning.
- Rare administrative plugins executing scripts on the server host.
level: high
---
title: TeamCity Server Child Process Shell Execution on Linux
id: 4b1c8d62-7f3a-4e59-91c6-2a8f3d5b7e09
status: experimental
description: Detects the TeamCity server Java process on Linux spawning shells or common post-exploitation utilities, consistent with RCE exploitation of CVE-2026-63077.
references:
- https://thehackernews.com/2026/08/cisa-flags-teamcity-cve-2026-63077-rce.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/15
tags:
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/java'
selection_parent_cmd:
ParentCommandLine|contains:
- 'TeamCity'
- 'teamcity'
- 'catalina'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/netcat'
- '/python'
- '/python3'
- '/perl'
- '/whoami'
- '/id'
- '/base64'
- '/chmod'
- '/chown'
condition: selection_parent and selection_parent_cmd and selection_child
falsepositives:
- Server-side plugins or health-check scripts executed under the TeamCity server context. Review and allow-list known script paths.
level: high
---
title: Suspicious Outbound Network Connection from TeamCity Server Process
id: 7d3a9f15-2e6b-4c48-8a1d-5c9e2f7a4b63
status: experimental
description: Detects the TeamCity server process initiating outbound connections to uncommon external ports, potentially indicating C2 communication or data exfiltration after exploitation of CVE-2026-63077.
references:
- https://thehackernews.com/2026/08/cisa-flags-teamcity-cve-2026-63077-rce.html
- https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/08/15
tags:
- attack.command_and_control
- attack.t1071
- attack.exfiltration
logsource:
category: network_connection
product: windows
detection:
selection:
Image|endswith:
- '\java.exe'
- '\javaw.exe'
- '\TeamCityService.exe'
Initiated: 'true'
filter_infrastructure:
DestinationIp|startswith:
- '10.'
- '172.16.'
- '192.168.'
filter_expected_ports:
DestinationPort:
- 443
- 80
condition: selection and not 1 of filter_*
falsepositives:
- Outbound connections to external artifact repositories, license servers, or plugin update feeds on non-standard ports. Baseline and allow-list known destinations.
level: medium
KQL — Microsoft Sentinel / Defender
This hunt assumes Defender for Endpoint coverage on your TeamCity hosts (strongly recommended) and/or Syslog ingestion for Linux build servers. It looks for the TeamCity server process tree producing shells, downloaders, and reconnaissance commands — the universal post-exploitation signature of CI/CD server compromise.
// Hunt: TeamCity server process spawning suspicious child processes (post-RCE behavior for CVE-2026-63077)
let TeamCityServerImages = dynamic(["java.exe", "javaw.exe", "TeamCityService.exe", "teamcity-server.exe", "java", "java.exe"]);
let SuspiciousChildren = dynamic([
"cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe",
"certutil.exe", "bitsadmin.exe", "wscript.exe", "cscript.exe", "curl.exe", "wget.exe",
"net.exe", "net1.exe", "whoami.exe", "nltest.exe", "ipconfig.exe",
"sh", "bash", "dash", "zsh", "curl", "wget", "nc", "ncat", "python", "python3", "perl", "base64", "chmod"
]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any (TeamCityServerImages)
or InitiatingProcessCommandLine has_any ("TeamCity", "teamcity", "catalina")
| where FileName has_any (SuspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, AccountName, InitiatingProcessAccountName, SHA256, ReportId
| sort by TimeGenerated desc
// Hunt: Inbound connections to TeamCity web interface (8111) from unexpected sources + outbound C2 from server process
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where (LocalPort == 8111 and ActionType == "InboundConnectionAccepted")
or (InitiatingProcessFileName in~ ("java.exe", "javaw.exe", "TeamCityService.exe", "java") and ActionType == "ConnectionSuccess" and RemotePort !in (443, 80, 8111, 9090))
| project TimeGenerated, DeviceName, ActionType, LocalPort, RemoteIP, RemotePort,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by TimeGenerated desc
Note: tune the has_any ("teamcity", "catalina") initiator match to your actual install paths to reduce noise — on dedicated build servers the hit rate should be near zero, and any hit deserves immediate triage.
Velociraptor VQL
For DFIR teams validating whether a TeamCity host was compromised, this artifact surfaces suspicious process trees and recent webshell-like file writes in the TeamCity web application directory.
-- Artifact: SecurityArsenal.TeamCity.PostExploit
-- Triages TeamCity servers for post-RCE indicators related to CVE-2026-63077
-- 1. Java/TeamCity processes with suspicious command lines or shell children
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)java|teamcity' AND CommandLine =~ '(?i)cmd|powershell|/bin/sh|/bin/bash|curl |wget |nc |base64|certutil')
OR (Name =~ '(?i)cmd.exe|powershell.exe|pwsh|sh$|bash$|nc$|curl$|wget$'
AND Ppid IN (SELECT Pid FROM pslist() WHERE Name =~ '(?i)java|teamcity'))
-- 2. Recently written executable/script content in TeamCity web directories (webshell triage)
LET webroot_globs = list(
'/opt/teamcity/webapps/**', '/opt/TeamCity/webapps/**', '/usr/local/teamcity/webapps/**',
'C:/TeamCity/webapps/**', 'C:/TeamCity/**/work/**'
)
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=webroot_globs)
WHERE (FullPath =~ '(?i)\.jsp$|\.jspx$|\.war$|\.sh$|\.ps1$|\.exe$'
AND Mtime > now() - 1209600) -- last 14 days
ORDER BY Mtime DESC
Verification & Hardening Script
Run this on Linux TeamCity server hosts to check the installed version, confirm the service state, review recent suspicious child processes, and verify network exposure. (For Windows hosts, use the Sigma/KQL content above plus the JetBrains installer to confirm patch level.)
#!/bin/bash
# Security Arsenal - TeamCity CVE-2026-63077 verification & exposure check (Linux)
# Run as root on the TeamCity SERVER host (not build agents).
echo "=== [1] Installed TeamCity version ==="
# Locate the TeamCity install directory and read the build number
for dir in /opt/TeamCity /opt/teamcity /usr/local/TeamCity /home/teamcity/TeamCity; do
if [ -d "$dir" ]; then
echo "Install dir found: $dir"
grep -ri "build.number" "$dir/conf/version.properties" 2>/dev/null || cat "$dir/conf/version.properties" 2>/dev/null
fi
done
# Also check via running process
ps aux | grep -i "[t]eamcity\|[c]atalina" | head -5
echo ""
echo "=== [2] Service status ==="
systemctl status teamcity-server 2>/dev/null | head -8 || service teamcity status 2>/dev/null
echo ""
echo "=== [3] Suspicious child processes spawned by TeamCity/Java (last boot) ==="
# Any shell/downloader spawned by the server process is a red flag
ps -eo pid,ppid,comm,args --forest | grep -iE "java|teamcity" | grep -iE "sh$|bash|dash|curl|wget|nc |ncat|python|perl|base64|chmod" || echo "No suspicious children found."
echo ""
echo "=== [4] Recent suspicious files in webapp directories (last 14 days) ==="
find /opt/teamcity/webapps /opt/TeamCity/webapps /usr/local/teamcity/webapps -type f \( -name "*.jsp" -o -name "*.jspx" -o -name "*.sh" -o -name "*.war" \) -mtime -14 2>/dev/null -exec ls -la {} \;
echo ""
echo "=== [5] Network exposure: is TeamCity reachable beyond localhost? ==="
ss -tlnp | grep -E ":8111|:8112" || netstat -tlnp 2>/dev/null | grep -E ":8111|:8112"
echo ""
echo "=== [6] Outbound connections from TeamCity process ==="
ss -tnp | grep -i java | grep -v "ESTAB.*:443" | head -20
echo ""
echo "=== ACTION REQUIRED ==="
echo "1. If the installed build number is below the fixed release in the JetBrains advisory, UPGRADE IMMEDIATELY: https://www.jetbrains.com/teamcity/download/"
echo "2. Review JetBrains security bulletin for CVE-2026-63077: https://www.jetbrains.com/privacy-security/issues-fixed/"
echo "3. If port 8111 is internet-reachable, restrict it NOW (firewall/reverse proxy + auth) and initiate IR review of sections [3]-[5] output."
Remediation
1. Patch — Immediately
- Upgrade on-premise TeamCity server to the latest fixed release published by JetBrains. Download from the official portal: https://www.jetbrains.com/teamcity/download/
- Review the specific fixed build numbers and full details in the JetBrains security bulletin: https://www.jetbrains.com/privacy-security/issues-fixed/
- TeamCity Cloud instances are managed by JetBrains and do not require customer action for server-side patching — but validate any on-prem build agents are also current.
- Treat the CISA KEV remediation deadline as your own: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Do not defer this to the next patch cycle.
2. Reduce Exposure — Today, Before Patching If Necessary
If you cannot patch within hours, take the server off the attack surface:
- Remove internet exposure. TeamCity server should never be directly internet-reachable. Place it behind a VPN, zero-trust access gateway, or at minimum an authenticating reverse proxy (with SSO/MFA) and IP allow-listing.
- Firewall the management interface (default TCP 8111) to only authorized administrator and agent subnets. Build agents communicate with the server — scope that traffic explicitly rather than leaving the port open to the whole flat network.
- Segment the CI/CD VLAN. The build server should not have unrestricted east-west reachability to production, domain controllers, or user subnets. It needs its artifact repo, its VCS, and its deployment targets — nothing more.
3. Hunt Before You Patch
Patching erases nothing — if the box was already popped, an upgrade does not evict the adversary. Because exploitation is confirmed in the wild and the flaw is unauthenticated, assume exposure if your server was network-reachable:
- Run the Sigma/KQL/VQL detections above across all TeamCity server hosts covering at least the last 30 days of telemetry.
- Review TeamCity web access logs for anomalous unauthenticated requests, scanner User-Agents, and requests from IPs with no legitimate business accessing your CI.
- Audit build configurations and project settings for unauthorized modifications — new build steps, changed VCS roots, unfamiliar webhooks, or new user accounts and tokens in the TeamCity UI.
- If any post-exploitation indicator fires, treat it as a full IR engagement: isolate the host, preserve memory and disk images, and rotate every credential the server could touch (VCS tokens, deployment keys, cloud credentials, artifact repo passwords, signing keys). Credential rotation is non-negotiable — assume all pipeline secrets are burned.
4. Longer-Term Hardening
- Move secrets out of the build server. Use a dedicated secrets manager with short-lived, workload-issued credentials (OIDC federation to cloud providers) instead of static tokens stored in TeamCity.
- Endpoint detection on build infrastructure. EDR coverage on CI/CD servers is consistently one of the biggest visibility gaps we find in assessments. These are production-critical hosts — instrument them like it.
- Immutable infrastructure for CI. Where feasible, run TeamCity as infrastructure-as-code so a clean rebuild is a pipeline run, not a forensic reconstruction project.
- Vulnerability management SLAs for KEV. Any CVE added to the CISA KEV catalog that touches internet-facing or credential-rich infrastructure should carry a 24–72 hour remediation SLA in your organization. CI/CD servers are exactly the asset class that warrants it.
The Bottom Line
CVE-2026-63077 combines the three attributes that demand immediate action: unauthenticated exploitation, confirmed in-the-wild activity, and a target that sits at the center of your software supply chain. Patch your on-prem TeamCity servers now, verify they were not already compromised, restrict who can reach them, and rotate pipeline credentials if there is any doubt. In fifteen years of IR work, the organizations that fare worst in CI/CD compromises are the ones that patched quickly but never hunted — the attacker simply kept the access they had already won.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.