TeamCity CVE-2026-63077 Active Exploitation

JetBrains is the software vendor behind TeamCity and widely used developer products such as IntelliJ IDEA and PyCharm. TeamCity is a CI/CD or build server: it monitors code repositories, sends build and test work to connected agents, collects results, stores or publishes build artifacts, and can trigger deployment stages. Organizations can run TeamCity On-Premises themselves or use JetBrains-hosted TeamCity Cloud.^{16, 17}

In business terms, TeamCity can serve as the control room for a software factory. It may hold credentials and trusted connections to proprietary source code, package and artifact stores, signing systems, cloud services, and production deployment targets. An attacker who controls it may be able to steal code or secrets, alter trusted software, tamper with releases, move into connected systems, or create risk for customers receiving affected software. The actual blast radius depends on the access granted in each environment.^{2, 8, 16}

JetBrains said on August 7 that it had received reports of active exploitation and attempted exploitation targeting unpatched TeamCity servers. That supersedes only the original advisory's disclosure-time statement that the vendor was not then aware of exploitation; both dated facts remain accurate in their time windows.^{1, 2}

The confirmed entry condition is HTTP or HTTPS reachability to TeamCity On-Premises. No account or user action is required. The attacker abuses the agent polling protocol, bypasses authentication checks, and can run arbitrary operating-system commands as the TeamCity server process.^{1, 2, 4}

JetBrains states that successful exploitation could expose TeamCity data, configuration, and stored credentials; modify server state; and compromise build artifacts or downstream CI/CD pipelines. These are conditional capabilities, not proof that every attempt produced each outcome.^{1, 2}

The vendor directs administrators to review logs for com.thoughtworks.xstream.converters.ConversionException and, on fixed or plugin-protected servers, com.thoughtworks.xstream.security.ForbiddenClassException. It also calls out unauthorized agents whose names begin with scan. Each signal requires contextual investigation.¹

Durable remediation is TeamCity 2025.11.7 or 2026.1.3. A CVE-specific security patch plugin supports TeamCity 2017.1 and later when an immediate upgrade is impossible. TeamCity Cloud customers need no action because mitigations were already applied.^{1, 2, 7}

No reliable retained source publishes issue-specific attacker IP addresses, domains, malicious URLs, filenames, hashes, actor names, victim identities, successful-compromise counts, or ransomware linkage. Behavioral evidence and local telemetry must control scoping.^{1, 3, 4}

JetBrains is a global software company that develops tools used by programmers and engineering teams. TeamCity is JetBrains' continuous integration and continuous delivery platform. A TeamCity server watches source-code repositories for changes, coordinates automated compilation and testing on build agents, collects results, stores or publishes build artifacts, and may authorize later deployment stages. TeamCity On-Premises is installed and managed by the customer; TeamCity Cloud is hosted and protected by JetBrains.^{16, 17}

This function places TeamCity between developers' source code and the software an organization releases. It can be trusted by proprietary repositories, build configurations, API tokens, SSH keys, package registries, artifact repositories, code-signing services, cloud accounts, deployment credentials, and production environments. A compromise can therefore steal intellectual property or secrets, alter build instructions or outputs, implant malicious code into trusted artifacts, reach connected infrastructure, or create downstream risk for customers. These are plausible impact paths; a specific incident requires local evidence.^{2, 8, 16}

The status is now materially different from initial disclosure. JetBrains's August 7 follow-up says it received reports of active exploitation and attempted exploitation targeting unpatched TeamCity servers. CISA had added CVE-2026-63077 to the Known Exploited Vulnerabilities catalog on August 5 and assigned an August 8 required-action date. The original July 27 statement that JetBrains was then unaware of exploitation is retained only as a dated historical fact.^{1, 2, 3}

CVE-2026-63077 affects TeamCity On-Premises servers reachable over HTTP or HTTPS. An unauthenticated attacker can abuse the TeamCity agent polling protocol to bypass authentication checks and execute arbitrary operating-system commands with the privileges of the TeamCity server process. No user action is required. The JetBrains CNA scores it CVSS 3.1 9.8 Critical and maps it to CWE-502, Deserialization of Untrusted Data; NVD had not supplied an independent score at the cutoff.^{1, 2, 4, 5, 6}

TeamCity is a CI/CD control plane, so host compromise can cross multiple trust boundaries. JetBrains says a successful exploit could expose TeamCity data, configuration, and stored credentials, modify server state, and potentially compromise build artifacts and downstream pipelines. In a particular environment, the actual blast radius follows the server process account, repository and registry tokens, signing material, deployment credentials, build-agent relationships, and accessible secrets. Those are investigation hypotheses until local evidence establishes use or change.^{1, 2, 8}

JetBrains now supplies concrete hunt signals. Administrators should search TeamCity server logs for com.thoughtworks.xstream.converters.ConversionException, which may indicate an attempted or successful exploit but does not confirm either. Systems already upgraded or protected by the plugin may record com.thoughtworks.xstream.security.ForbiddenClassException when an exploit attempt was successfully blocked. Administrators should also review unauthorized build agents for unexpected names beginning with scan and use relevant log timestamps, not the unauthorized-agent display date, to build the timeline.¹

The fixed releases are TeamCity 2025.11.7 and 2026.1.3. JetBrains also provides a security patch plugin for TeamCity 2017.1 and later if immediate upgrade is impossible. Versions 2017.1 through 2018.1 require a restart after plugin installation; from 2018.2 the plugin can be enabled without restart. The plugin addresses this CVE only, so a supported full upgrade remains the preferred durable state. TeamCity Cloud customers need no action, and JetBrains says it found no Cloud exploitation through this issue.^{1, 2, 7}

Administrators must not treat automatic update settings as proof of remediation. TeamCity 2024.03 and newer can automatically download available security patch plugins and notify administrators, but a system administrator must review and apply the pending patch. Full-version automatic update is a separate, administrator-controlled process and is unavailable for some installations, including Docker. Protection must be proven with the exact running version or active security patch plugin.^{2, 7, 8}

A reachable server that was vulnerable during the exploitation window requires more than a patch ticket. Preserve TeamCity, reverse-proxy, firewall, system, EDR, identity, VCS, artifact, registry, signer, secret-store, deployment, and build-agent telemetry; record the pre-change build; restrict reachability; remediate; validate the new runtime; and hunt the vulnerable period. If command execution or unexplained privileged CI/CD changes appear, move into incident response, rotate reachable trust, validate artifacts and releases from known-good inputs, and rebuild when integrity cannot be established.^{1, 3, 7, 8}

SMBs may have limited staff, short retention, and a TeamCity service identity with broad shared privileges. MSPs face an additional concentration risk: one management pattern may touch multiple customer environments, yet evidence must remain customer- and server-specific. Insurers and counsel should request the inventory, exposure interval, remediation proof, preserved evidence, confirmed access, affected trust paths, recovery actions, and remaining uncertainty rather than accepting a statement that the product was simply patched.^{1, 3, 8}

The public record does not provide reliable issue-specific attacker IP addresses, domains, malicious URLs, filenames, file hashes, named actors, victim identities, campaign scale, or successful-impact counts. CISA lists ransomware use as unknown. Public exploit status is not established by the retained primary sources. These absences prohibit blocklist invention and attribution; they do not lower response urgency or prove that no such information exists privately.^{1, 3, 4}