Active exploitation of TeamCity RCE puts CI/CD control planes on the front line

JetBrains TeamCity administrators have a narrow patch window for CVE-2026-63077, a critical unauthenticated remote code execution vulnerability affecting TeamCity On-Premises. The issue was disclosed by JetBrains on July 27, 2026, fixed in versions 2025.11.7 and 2026.1.3, and later added to CISA's Known Exploited Vulnerabilities catalog after evidence of active exploitation.

The important detail is where this bug lives. TeamCity is not just another web application. It often sits at the center of software delivery, connected to source repositories, build agents, package registries, artifact stores, deployment credentials, signing workflows, and environment secrets. A successful remote code execution bug on that control plane can therefore turn into much more than server compromise.

JetBrains says an unauthenticated attacker with HTTP or HTTPS access to a vulnerable TeamCity server may bypass authentication checks and execute arbitrary operating system commands with the privileges of the TeamCity server process. NVD lists the issue as a deserialization of untrusted data vulnerability with a CVSS 3.1 score of 9.8. CISA's KEV entry sets an August 8, 2026 remediation due date for U.S. federal civilian agencies and classifies the exploitation state as active.

For enterprise defenders, the message is direct: internet-reachable TeamCity should be patched or shielded immediately, and already-exposed servers should be reviewed as potentially compromised CI/CD infrastructure.

What happened

JetBrains published its advisory for CVE-2026-63077 on July 27, 2026. The vendor said all TeamCity On-Premises versions were affected and that the issue had been fixed in TeamCity 2025.11.7 and 2026.1.3. For organizations unable to upgrade quickly, JetBrains also released a security patch plugin for TeamCity 2017.1 and later.

The vulnerability involves the TeamCity agent polling protocol, which build agents use to communicate with the TeamCity server. According to NVD, unauthenticated remote code execution was possible through that protocol in vulnerable versions. JetBrains describes the attack path as available to an unauthenticated attacker who can reach the TeamCity server over HTTP or HTTPS.

On August 5, 2026, CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities catalog. That changed the urgency of the advisory. The issue was no longer only a critical patch announcement; it had become a live exploitation case with a federal remediation clock.

Public reporting from The Hacker News and SecurityWeek reinforced the same timeline: a recently patched TeamCity vulnerability had moved into active exploitation shortly after disclosure. As of those reports, public details about the exploitation method, threat actors, and victim scale remained limited.

Why TeamCity compromise matters

A TeamCity server frequently has access that normal application servers do not. It may retrieve source code, orchestrate build agents, handle environment variables, publish artifacts, sign releases, run deployment scripts, and connect to cloud or package registries. In many organizations, CI/CD systems are trusted to turn source code into production change.

That makes CI/CD compromise strategically valuable. If an attacker can execute commands on the TeamCity server process, the immediate blast radius depends on local privileges and configuration. But the realistic concern extends to credentials, pipeline integrity, build artifacts, and downstream environments.

This is why CI/CD vulnerabilities should be treated as supply chain attack risks, not only infrastructure patching tasks. A compromised build server can become a bridge between source control and production. It can also provide attackers with trusted paths to alter software, collect secrets, or poison artifacts that other systems later consume.

JetBrains explicitly warns that the impact of successful exploitation varies based on the permissions granted to the TeamCity server process. That is the operational lesson. A hardened, least-privilege TeamCity deployment is still exposed to the vulnerability until patched, but it may limit what attackers can reach after gaining execution. A server with broad secrets and network reach gives attackers a much easier route into the software delivery chain.

What defenders should do first

The primary remediation is to update TeamCity On-Premises to 2025.11.7 or 2026.1.3. JetBrains recommends upgrading rather than relying permanently on the patch plugin, because fixed product versions include broader security updates beyond CVE-2026-63077.

Organizations that cannot upgrade immediately should apply JetBrains' security patch plugin for supported TeamCity 2017.1 and later deployments. Older TeamCity installations should be treated with particular caution, because the patch plugin support boundary may not cover every legacy environment.

Network exposure should be reduced at the same time. JetBrains recommends that internet-facing TeamCity servers require VPN access or an additional access control layer. That advice is especially relevant now that exploitation is active. Removing public reachability does not replace patching, but it can reduce opportunistic scanning and exploitation while remediation is underway.

Defenders should prioritize these actions:

• Upgrade TeamCity On-Premises to 2025.11.7 or 2026.1.3
• Apply JetBrains' security patch plugin only where an immediate full upgrade is not possible
• Restrict TeamCity access to trusted networks, VPN users, or approved reverse-proxy controls
• Identify all internet-exposed TeamCity servers, including forgotten test or migration instances
• Review TeamCity server and build-agent privileges, stored credentials, tokens, and deployment secrets
• Rotate credentials exposed to vulnerable servers if compromise is suspected or cannot be ruled out
• Inspect build history, plugin changes, administrator actions, agent registration events, and suspicious process execution
• Rebuild and validate sensitive artifacts produced during the exposure window if server integrity is uncertain

Incident response considerations

Because TeamCity sits inside the delivery pipeline, incident response should not stop at confirming the installed version. Teams should determine whether attackers had practical access to the vulnerable service before it was patched or isolated.

Useful evidence includes web access logs, TeamCity server logs, agent communication records, newly created users or tokens, plugin installation activity, unexpected build configurations, changes to project settings, suspicious build steps, and command execution from the TeamCity server process. If logs show unusual requests around the agent polling protocol or unexplained server-side process creation, defenders should escalate from patch management to full incident response.

Credential review is also essential. TeamCity deployments often store or broker access to Git repositories, container registries, package managers, SSH keys, deployment systems, cloud services, and signing tools. If the TeamCity process could read those secrets, defenders should assume the attacker may have been able to read them as well.

For build agents, check whether any jobs ran unexpectedly, whether artifacts were published outside normal release windows, and whether runners contacted unusual external infrastructure. Even if the initial exploit targeted the server, agents may inherit sensitive environment variables or execute attacker-controlled build steps.

The bigger lesson for CI/CD security

CVE-2026-63077 is another reminder that CI/CD systems are production-adjacent assets. They may not serve customers directly, but they decide what customers eventually receive. That makes them attractive targets for attackers who want code execution, credential theft, persistence, or trusted distribution paths.

Good CI/CD security starts with boring controls: patch quickly, reduce internet exposure, enforce least privilege, segment build networks, minimize long-lived secrets, monitor administrative changes, and maintain reliable logs. The value is not theoretical. When a critical unauthenticated RCE lands in a build control plane, these controls decide whether the incident is a contained patch event or a supply chain investigation.

For TeamCity specifically, the immediate path is clear. Patch to 2025.11.7 or 2026.1.3, apply the security plugin only as a temporary bridge where necessary, restrict access to the service, and review exposed servers for signs of compromise. The exploitation window is now real, and CI/CD control planes deserve the same urgency as internet-facing identity, VPN, and edge infrastructure.

References

1. Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077) - Update to 2025.11.7 or 2026.1.3 Now
2. CVE-2026-63077 Detail
3. Known Exploited Vulnerabilities Catalog entry for CVE-2026-63077
4. CVE-2026-63077: Critical unauthenticated remote code execution in JetBrains TeamCity
5. CISA Flags TeamCity CVE-2026-63077 RCE Flaw Under Active Exploitation in the Wild
6. Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability