CVE-2026-63077 is an unauthenticated remote code execution flaw in JetBrains TeamCity On-Premises, reachable through the agent polling protocol. NVD scores it 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and classifies it as CWE-502, deserialization of untrusted data. JetBrains published its advisory on July 27, 2026, crediting a private report from Antoni Tremblay on July 10, and shipped fixes in 2026.1.3 and 2025.11.7. At disclosure JetBrains stated it was not aware of active exploitation. CISA added the CVE to the Known Exploited Vulnerabilities catalog on August 5, 2026 with an August 8 remediation deadline, which is the event that changes the priority: a bug that had been patchable for nine days is now confirmed under exploitation. TeamCity Cloud is not affected.
Two data points are worth flagging before the operational detail. First, EPSS for this CVE sits around 0.006 across FIRST and Tenable, which is a probability model that has not yet absorbed the KEV listing. Do not let a low EPSS deprioritise a CVE that CISA has already marked exploited. Second, CISA's own SSVC block records automatable: yes and technicalImpact: total, which is the assessment that should drive scheduling here.
Am I vulnerable?
Exposure is a function of version, not configuration. The flaw sits in the protocol path that build agents use to poll for work, and JetBrains documents that path as an ordinary agent-initiated HTTP(S) connection to the same URL and port as the web UI: "Agents use unidirectional agent-to-server connection via the polling protocol: an agent establishes an HTTP(S) connection to the TeamCity Server, and polls the server periodically for server commands." There is no separate agent port to firewall independently. If a host can reach your TeamCity web interface, it can reach the vulnerable code path.
Affected versions
| Product |
Vulnerable range |
Fixed in |
| TeamCity On-Premises (2026.1 branch) |
2026.1 up to but excluding 2026.1.3 |
2026.1.3 |
| TeamCity On-Premises (all earlier branches) |
All versions before 2025.11.7 |
2025.11.7 |
| TeamCity On-Premises 2017.1+ that cannot upgrade |
As above |
Security patch plugin fix_CVE_2026_63077.zip |
| TeamCity Cloud |
Not affected |
No customer action required |
Diagnostic commands
Read-only checks to confirm exposure:
- Server version via REST (authoritative):
curl -4 -sS -H "Authorization: Bearer <token_value>" 'https://teamcity.example.com/app/rest/server'. Returns a <server ... version="..." buildNumber="..."/> element. Vulnerable if the version is below 2026.1.3 on the 2026.1 branch or below 2025.11.7 on any earlier branch.
- Build-number marker on disk (no credentials needed):
ls -1 "$TEAMCITY_HOME" | grep '^BUILD_'. On Windows the default home is C:\TeamCity, so dir C:\TeamCity\BUILD_*. JetBrains documents this file as the server application build number; map it to a release through the release notes.
- Patch plugin applied?:
ls -l "$TEAMCITY_DATA_PATH/plugins/" | grep -i 'fix_CVE_2026_63077'. No output on a pre-fix build means the host is unmitigated. Cross-check under Administration | Plugins. On 2017.1 through 2018.1 the file being present is not sufficient: the server must also have been restarted.
- Container image state:
docker ps --filter 'ancestor=jetbrains/teamcity-server' --format '{{.Names}}\t{{.Image}}', then docker inspect --format '{{.Created}}' <container>. Treat a :latest tag as unknown rather than patched. An image pulled before July 27, 2026 is vulnerable regardless of the tag name.
- Listener exposure:
ss -lntp | grep -i java. A Java listener bound to 0.0.0.0 or :: on the TeamCity port (commonly 8111) means the polling path is reachable from every network the host sits on. A loopback bind behind an access-controlled reverse proxy is the lower-exposure state.
Vulnerability
The agent polling protocol deserialises data supplied by the caller before the server has established who the caller is. CWE-502 describes the class: an application reconstructs an object graph from untrusted bytes, and reconstruction itself invokes application code paths that the sender chose. In a Java server that carries a large gadget surface, because any class on the classpath with side effects during deserialization becomes reachable. The consequence here is command execution as the TeamCity server account, with no credential, no user interaction, and no prior access.
SecurityOnline's write-up describes the request as arriving at the same endpoint build agents use to request jobs, with the server deserialising attacker-controlled objects while bypassing the authentication check. Rapid7's Emergent Threat Response advisory frames the same behaviour as authentication bypass leading to OS command execution at the privilege level of the server process, and shipped vulnerability checks to InsightVM and Nexpose on July 28.
The operational significance is where the sink sits. Agent polling is infrastructure plumbing rather than a user-facing feature, so it tends not to be covered by the WAF rules, rate limits, or authentication middleware that a team layers over the web UI. On an internet-facing TeamCity server the two are the same listener, and a control that protects one protects both only if it is applied at the network layer rather than the application layer.
Threat model
Who would exploit this: The unauthenticated network vector, the trivially fingerprintable TeamCity login page, and a widely publicised vendor advisory make this a natural fit for opportunistic criminal operators running internet-wide scans, principally initial-access brokers and ransomware affiliates who monetise a foothold rather than the software itself. State-aligned actors are a credible second category, because TeamCity servers hold source code, signing material, and deployment credentials for the organisations that build software. Insider misuse is the least relevant profile: the flaw removes the need for any credential, so an attacker with existing access gains little from it.
What they are after:
- Initial foothold and persistence on the build server, executing as the TeamCity service account and surviving restarts through server configuration, scheduled tasks, or a malicious plugin
- Credential and secret harvesting: stored VCS tokens, SSH deploy keys, artifact repository and container registry credentials, cloud deployment roles, and secrets held in project parameters
- Source code exfiltration, since the server holds working credentials to every connected repository
- Lateral movement into the connected build agent fleet and the networks those agents reach, using the server's legitimate command channel
- Build pipeline and supply chain tampering, altering build steps or artifacts so modified output flows downstream
- Ransomware staging, using harvested credentials and the agent fleet for pre-encryption discovery and distribution
Attack chain: An unauthenticated attacker who can reach the server over HTTP or HTTPS interacts with the agent polling protocol, which deserialises attacker-controlled data and bypasses the authentication check. That yields OS command execution as the TeamCity server account. From there the attacker reads server configuration and stored credential material, and can issue instructions to connected agents through the server's normal trusted channel, which is why post-exploitation activity blends into legitimate CI traffic.
Blast radius: A compromised TeamCity server is a credential vault as much as a build host. It typically holds VCS tokens and deploy keys for every connected repository, artifact and registry credentials, cloud roles assumed during release jobs, and in some deployments signing material, so the practical exposure is the organisation's source code plus authenticated access to whatever the pipeline deploys to. The agent fleet extends that reach, because agents commonly sit in networks the server cannot address directly. Patching does not invalidate secrets already read, so credential rotation belongs in the recovery plan alongside the upgrade.
No primary source has published attribution, victimology, or indicators for this CVE. The Hacker News and SecurityWeek both state explicitly that the operators and the scale of activity are unknown as of August 6. Prior TeamCity CVEs have a documented record: CISA and partner agencies attributed exploitation of CVE-2023-42793 to Russian SVR-affiliated actors, and GuidePoint Security documented BianLian ransomware operators exploiting CVE-2024-27198. Those are precedent for how attackers have treated TeamCity servers, not attribution for this vulnerability.
Mitigation
Patch
| Branch |
Upgrade to |
| TeamCity 2026.1.x |
2026.1.3 |
| All earlier branches |
2025.11.7 |
TeamCity 2024.03 and later automatically download available security patch plugins and notify administrators. For servers on 2017.1 or later that cannot take a full upgrade immediately, JetBrains published fix_CVE_2026_63077.zip, distributed from download.jetbrains.com/teamcity/plugins/internal/. From 2018.2 onward the plugin can be enabled without a restart; on 2017.1 through 2018.1 a server restart is required.
Configuration mitigation
Apply the vendor security patch plugin (2017.1+ servers not yet upgraded):
# JetBrains-documented plugin path: <TeamCity Data Directory>/plugins
echo "$TEAMCITY_DATA_PATH"
cp fix_CVE_2026_63077.zip "$TEAMCITY_DATA_PATH/plugins/"
# 2018.2+: enable via Administration | Plugins (no restart required)
# 2017.1 - 2018.1: restart the TeamCity server after copying
ls -l "$TEAMCITY_DATA_PATH/plugins/" | grep -i 'fix_CVE_2026_63077'
Restrict the HTTP(S) listener to build agents and admin ranges. This implements JetBrains' guidance to limit access to trusted networks and, for internet-facing servers, to require VPN or an additional security layer. Because agent polling shares the main listener, the restriction has to be by source address:
# Replace 10.0.0.0/24 with your build-agent subnet, 10.0.9.0/24 with admin/VPN.
TC_PORT=8111
iptables -A INPUT -p tcp --dport "$TC_PORT" -s 10.0.0.0/24 -j ACCEPT # build agents
iptables -A INPUT -p tcp --dport "$TC_PORT" -s 10.0.9.0/24 -j ACCEPT # admins / VPN
iptables -A INPUT -p tcp --dport "$TC_PORT" -j DROP # everything else
# Verify from an off-allowlist host:
# curl -4 -sS -m 5 -o /dev/null -w '%{http_code}\n' http://teamcity.example.com:8111/
Compensating controls
- Rotate what the server held. If the host was internet-reachable on a vulnerable build, treat VCS tokens, deploy keys, registry credentials, and cloud role bindings as exposed and rotate them. The upgrade closes the door; it does not recall the keys.
- Audit administrative state. Review TeamCity users, roles, and access tokens for entries created without a corresponding authenticated session. Rogue admin accounts and tokens were the signature post-exploitation step on both prior TeamCity CVEs.
- Segment the agent fleet. Agents should not have standing credentials to production or to networks unrelated to their builds. This limits what the server's command channel is worth to an attacker who holds it.
- Take the server off the public internet. JetBrains' own guidance is VPN or an equivalent access layer for internet-facing installations. A CI server rarely needs unauthenticated global reachability.
Detection (starter rules, validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production. No public indicators of compromise have been published for this CVE, so everything below is behavioural.
Network and log signals
- The TeamCity server JVM (the Tomcat/catalina process under the TeamCity service account) spawning
/bin/sh, bash, cmd.exe, powershell.exe, curl, wget, or a scripting interpreter. Build agents legitimately spawn shells; the server process should almost never do so.
- Unauthenticated requests to the agent polling endpoints from source addresses outside the known build-agent pool. Agent-to-server polling is a small, stable set of source IPs, so any new source, cloud or VPS range, or unusually large POST body to those paths warrants review.
- Java serialized object data in request bodies or proxy/WAF captures: the raw magic header
AC ED 00 05, or the base64 prefix rO0AB in a parameter, header, or body field.
- Deserialization failure traces in
teamcity-server.log or catalina.out: java.io.StreamCorruptedException, java.io.InvalidClassException, ClassNotFoundException, or ObjectInputStream frames in the agent polling code paths. Failed probes leave these behind before a working attempt succeeds silently.
- New administrator accounts, roles, or access tokens in
teamcity-rest.log and teamcity-auth.log without a matching authenticated login immediately prior.
- New or modified files under
<TeamCity home>/webapps/ROOT or <TeamCity data dir>/plugins written by the server process, plus outbound connections from the server JVM to destinations that are neither repositories nor agents.
YARA
rule TeamCity_Suspicious_Java_Deserialized_Payload
{
meta:
description = "AI-generated STARTER rule. Java serialized object data combined with well-known deserialization gadget class names, as seen in payloads against Java services such as JetBrains TeamCity (CVE-2026-63077, CWE-502). Behavioural only: contains no CVE-specific file hashes."
author = "CVE Brief (AI-generated starter rule)"
date = "2026-08-07"
reference = "https://blog.jetbrains.com/teamcity/2026/07/cve-2026-63077/"
reference2 = "https://nvd.nist.gov/vuln/detail/CVE-2026-63077"
cve = "CVE-2026-63077"
confidence = "medium"
scope = "Intended for PCAP payload carving, proxy/WAF request-body captures, quarantined uploads, and temp/heap artifacts. Do NOT run across the TeamCity installation tree or a Maven/Gradle cache: those legitimately contain these library class names and will match."
validate = "Validate in your environment before deploying."
strings:
$ser_magic = { AC ED 00 05 }
$ser_b64 = "rO0AB" ascii wide
$g_invoker = "org.apache.commons.collections.functors.InvokerTransformer" ascii wide
$g_chained = "org.apache.commons.collections.functors.ChainedTransformer" ascii wide
$g_invoker4 = "org.apache.commons.collections4.functors.InvokerTransformer" ascii wide
$g_templates = "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl" ascii wide
$g_rome = "com.sun.syndication.feed.impl.ToStringBean" ascii wide
$g_beanutils = "org.apache.commons.beanutils.BeanComparator" ascii wide
$g_badattr = "javax.management.BadAttributeValueExpException" ascii wide
$g_groovy = "org.codehaus.groovy.runtime.ConvertedClosure" ascii wide
$g_c3p0 = "com.mchange.v2.c3p0.PoolBackedDataSource" ascii wide
condition:
filesize < 10MB
and any of ($ser_*)
and 1 of ($g_*)
}
Sigma
title: TeamCity Server JVM Spawning Command Interpreter (Possible CVE-2026-63077 Exploitation)
id: 7b3f5c2a-9d41-4e08-b6ac-0f2d81c4e57b
status: experimental
description: |
AI-generated STARTER rule. Detects the JetBrains TeamCity SERVER JVM (the Tomcat/catalina process)
spawning an operating system command interpreter or download utility. CVE-2026-63077 is an
unauthenticated deserialization RCE (CWE-502) in the TeamCity agent polling protocol; successful
exploitation executes commands with the privileges of the server process, so malicious commands
appear as direct children of that JVM. Deliberately scoped to the SERVER process: build agents
spawn shells as their normal function and are filtered out. Validate in your environment before
deploying, and tune the parent command line strings to match your own service definition.
references:
- https://blog.jetbrains.com/teamcity/2026/07/cve-2026-63077/
- https://nvd.nist.gov/vuln/detail/CVE-2026-63077
- https://www.jetbrains.com/help/teamcity/teamcity-server-logs.html
author: CVE Brief (AI-generated starter rule, not registered upstream)
date: 2026-08-07
tags:
- attack.initial-access
- attack.execution
- attack.t1190
- attack.t1059
- cve.2026-63077
logsource:
category: process_creation
detection:
selection_parent_jvm:
ParentImage|endswith:
- '/java'
- '\java.exe'
- '\javaw.exe'
selection_parent_teamcity:
ParentCommandLine|contains:
- 'teamcity-server'
- 'org.apache.catalina.startup.Bootstrap'
- 'catalina.base'
- 'TeamCity/bin'
- 'TeamCity\bin'
- 'teamcity_logs'
selection_child_proc:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/curl'
- '/wget'
- '/python3'
- '/perl'
- '/nc'
- '/ncat'
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
filter_build_agent:
ParentCommandLine|contains:
- 'buildAgent'
- 'agent.jar'
- 'jetbrains.buildServer.agent'
- 'launcher.jar'
condition: selection_parent_jvm and selection_parent_teamcity and selection_child_proc and not filter_build_agent
falsepositives:
- A build agent installed on the same host as the server (common in small deployments); every build step will fire this rule, so exclude that host or tighten the parent filter by service account
- Legitimate TeamCity maintenance activity: backup, database maintenance, log rotation, and upgrade scripts invoked from the server process
- Server-side plugin functionality that shells out (some VCS, Docker, and cloud-profile plugins call external binaries such as git, docker, or a cloud CLI)
- Monitoring, EDR, or configuration-management tooling executing helper processes under the TeamCity service account
- Administrator-initiated diagnostics from the server host (thread dumps, jstack, jcmd wrappers) run through a shell
level: high
Rule notes
The Sigma rule is the higher-value of the two: it catches the post-exploitation outcome (the TeamCity server JVM becoming the parent of a shell or download utility) rather than the payload, which makes it resilient to gadget-chain and encoding changes. It only fires if command execution is a visible child process, so in-JVM-only actions such as reading stored credentials or dropping a plugin through Java APIs are missed and must be covered by the file and REST-log signals above. The YARA rule pairs Java serialization markers with common gadget class names and is meant for network captures and quarantined artifacts only. Run it across a TeamCity install tree or a dependency cache and it will match benign library files. No reliable public IOCs or exploit samples were available at authoring time, so both rules need baselining before production deployment.
References