TeamCity Exploitation Puts Build Trust Under Review

JetBrains now says it has received reports of active and attempted exploitation of CVE-2026-63077 against unpatched TeamCity On-Premises servers. The critical vulnerability allows an unauthenticated attacker with HTTP or HTTPS access to use the agent polling protocol to execute operating system commands with the privileges of the TeamCity server process. CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 5.

The required fix is TeamCity 2025.11.7 or 2026.1.3. JetBrains also provides a security patch plugin for TeamCity 2017.1 and later when an immediate upgrade is impossible, but that plugin addresses only this CVE. Because a TeamCity server can hold repository, registry, cloud, notification, and signing-related access while directing build agents and artifacts, suspected exploitation is a software supply-chain incident. Recovery needs to establish the integrity of the server, connected agents, build configuration, credentials, caches, artifacts, and anything deployed from the affected window.

JetBrains says CVE-2026-63077 was reported privately on July 10 and published its first advisory on July 27. At that point, the company said it was not aware of active exploitation. It had already released TeamCity 2025.11.7 and 2026.1.3, plus a security patch plugin for older supported installations. The initial disclosure gave defenders a fix before the vendor publicly confirmed attacks.

CISA added the vulnerability to KEV on August 5 with an August 8 remediation date for covered federal systems. In an August 7 follow-up, JetBrains said it had received reports of both active exploitation and attempted exploitation targeting unpatched servers. This is the current operational state. The original no-exploitation statement describes what JetBrains knew on July 27, not a continuing assurance.

Neither the JetBrains posts nor the KEV entry publishes a named actor, total victim count, complete payload set, or full campaign timeline. They do establish that the issue moved beyond theory. Organizations with a vulnerable, reachable server during the period before remediation should determine exposure and review evidence rather than wait for attribution or a campaign-specific indicator package.

CVE-2026-63077 is an unauthenticated remote code execution flaw. JetBrains says an attacker who can reach a vulnerable TeamCity server over HTTP or HTTPS can exploit the agent polling protocol to bypass authentication checks and run operating system commands as the TeamCity server process. NVD classifies the weakness as deserialization of untrusted data and assigns a 9.8 CVSS base score.

TeamCity normally uses the polling protocol for agent-to-server communication. Agents establish HTTP or HTTPS connections to the server and regularly ask for commands. That expected protocol behavior is why perimeter rules designed only around the login screen or REST API may not express the real attack boundary. If an untrusted network can reach the server URL used for polling, it can reach the vulnerable surface described by the vendor.

The immediate operating-system impact depends on the service account. A TeamCity process running as root, SYSTEM, an administrator, or a privileged domain identity gives command execution more local or network authority than a dedicated low-privilege account. Least privilege does not remove the vulnerability, but it limits what the initial server process can do while responders patch and investigate.

JetBrains warns that successful exploitation could expose TeamCity data, configuration, and stored credentials, change server state, and compromise build artifacts or downstream pipelines. Its incident guidance lists common service connections including version-control systems, package and container registries, cloud profiles, notification systems, issue trackers, and custom project parameters. The exact blast radius is the set configured in the affected environment, not every integration the product can support.

Control of the server can also influence build agents. TeamCity agents receive build settings, source, credentials, artifacts, tools, and commands from the server. The product includes an Agent Terminal feature for authorized remote command access. If an attacker changed a build, installed a plugin, supplied a tool, or used agent access while controlling the server, the agent host and its service identity may become a second execution boundary.

Artifact integrity is the final link. A malicious build step or modified cache can produce output that appears to come from the normal CI path. Signing, publishing, or deployment automation may then carry it farther. This is a plausible consequence identified by the vendor, not proof that all exploitation altered builds. Teams need release-specific evidence before declaring artifacts safe or compromised.

Upgrade TeamCity On-Premises to 2025.11.7 or 2026.1.3 and verify the running build after restart. JetBrains says both maintenance releases include the fix. They also contain more than 20 security fixes, which is one reason the full upgrade is preferable to the narrow plugin. Inventory secondary servers, restored snapshots, test controllers, old containers, and disaster-recovery instances so a forgotten copy does not preserve the vulnerable service.

If an immediate upgrade is impossible, JetBrains provides a patch plugin for TeamCity 2017.1 and later. Versions 2017.1 through 2018.1 require a restart after plugin installation; versions from 2018.2 can enable it without restarting. The plugin fixes only CVE-2026-63077. Record its installed and enabled state, then schedule the complete product update rather than allowing the exception to become permanent.

TeamCity Cloud customers need no action for this vulnerability because JetBrains says it applied the necessary measures and found no evidence that TeamCity Cloud was exploited through this flaw. On-premises operators who cannot patch immediately should restrict external reachability. Longer term, limit server access to trusted networks or a VPN, use HTTPS for agent traffic, run the server with minimum privileges, and place production build agents on hosts separate from the server.

JetBrains recommends searching server logs for com.thoughtworks.xstream.converters.ConversionException. On a server that was vulnerable, this message may accompany an attempted or successful exploit and requires investigation. The vendor explicitly says the message alone does not confirm exploitation. Preserve the full event, timestamp, adjacent requests, process activity, and relevant proxy or network records before deciding what happened.

On a patched server, com.thoughtworks.xstream.security.ForbiddenClassException may show that the fix blocked an exploitation attempt. That is different from evidence of pre-patch compromise. JetBrains also recommends reviewing unauthorized build agents for unexpected entries, especially names beginning with scan. Use the related log timestamps for timing because the date displayed for an unauthorized agent does not necessarily show when the attempt occurred.

Expand the review beyond these named signals. Examine TeamCity audit events, operating-system process creation, new users and tokens, authentication settings, plugins, internal properties, tools, projects, build configurations, source-control changes, artifact publication, and log deletion or gaps. A missing vendor string is not proof of safety, particularly if logs can be changed from the compromised server context.

If compromise is suspected, JetBrains advises isolating the TeamCity server from internal and external networks. Preserve evidence before destructive cleanup. Build agents connected while the server was compromised are at risk if they ran modified builds, received a plugin, or were reached through Agent Terminal. Isolate and rebuild affected agents when their integrity cannot be demonstrated from reliable telemetry and known-good state.

Rotate access tokens and credentials available to TeamCity, then audit the corresponding services for unauthorized actions. This includes repositories, registries, cloud accounts, notification systems, issue trackers, and any secrets held in project parameters. Review user creation, authentication-module changes, plugins, tools, and internal properties. Rebuilding the server without revoking credentials can leave an attacker with access that no longer depends on TeamCity.

Treat artifacts and build caches produced from the earliest plausible compromise time until a trusted rebuild as unverified. Identify which releases were signed, published, or deployed during that interval. Rebuild critical artifacts from reviewed source on clean agents, compare provenance and hashes where available, and rotate signing material if exposure cannot be ruled out. The goal is not to assume every output is malicious; it is to restore evidence that the delivery chain produces what the organization intends.