Summary
- CISA has added CVE-2026-63077 to its Known Exploited Vulnerabilities catalogue after evidence of active exploitation.
- The flaw can allow an unauthenticated attacker to execute operating-system commands on TeamCity On-Premises.
- A compromised build server can expose credentials, configuration, build artefacts, and downstream CI/CD processes.
A critical vulnerability in TeamCity has moved from a patching problem to an active intrusion risk after US authorities confirmed exploitation in the wild.
JetBrains disclosed CVE-2026-63077 in late July, warning that an unauthenticated attacker able to reach a TeamCity On-Premises server over HTTP or HTTPS could execute operating-system commands with the privileges of the TeamCity server process.
The US Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities catalogue on 5 August. JetBrains had said when it published its original advisory that it was not aware of active exploitation, making CISA’s addition a material change in the evidence around the flaw.
All TeamCity On-Premises releases are affected unless updated or protected using JetBrains’ security patch plugin. The company fixed the vulnerability in TeamCity 2025.11.7 and 2026.1.3 and said TeamCity Cloud had already received protective measures.
The attack surface is unusually sensitive because continuous integration and continuous delivery systems routinely sit between source code, developers, signing processes, package repositories, and production infrastructure. TeamCity itself warns that exploitation could expose data, configuration, and credentials, modify server state, and potentially affect build artefacts and downstream CI/CD processes.
The vulnerability involves TeamCity’s agent polling protocol, but exploitation does not require an existing TeamCity account. Where a server is reachable, the flaw can create an unauthenticated route into infrastructure designed to orchestrate trusted software-development activity.
The initial TeamCity disclosure already raised software supply chain concerns. Confirmation of exploitation removes one of the significant uncertainties around the incident without establishing how many systems have been compromised or what attackers have done after obtaining access.
No public evidence currently shows widespread tampering with build artefacts or downstream software releases. Those possibilities should not be treated as confirmed consequences of the campaign. They describe what access to a compromised CI/CD environment could enable, depending on credentials, permissions, and separation between the TeamCity server and connected systems.
Build infrastructure carries a high concentration of operational trust. A conventional application server may serve one workload, while a build system can hold access to several repositories, cloud environments, signing services, secrets, and deployment processes. Compromise can therefore create a path from one exposed service into systems that produce software trusted elsewhere.
That architecture also complicates recovery. Rebuilding a vulnerable server may be only one part of the response if an attacker has already obtained reusable credentials or modified configuration. The integrity of builds produced during a suspected compromise may also need to be established separately from the security of the patched host.
European software-security regulation is increasing scrutiny of how products are developed, maintained, and updated. The Cyber Resilience Act places greater emphasis on secure development and vulnerability handling, while customers are paying closer attention to software provenance and supplier controls. Infrastructure responsible for producing releases consequently forms part of the assurance chain even when it is not itself shipped to customers.
JetBrains recommends restricting network access to TeamCity servers, running the service with minimum necessary operating-system privileges, and separating servers from build agents. Those controls can limit exposure and consequence, but they do not remove the need to address the vulnerable software now that exploitation has been confirmed.
CISA has not identified victims or published details of the observed attacks. The established position is narrower: CVE-2026-63077 can provide unauthenticated command execution against a high-trust development system, and attackers are now using it against real environments.
