Summary
- CVE-2026-63077 affects every version of TeamCity On-Premises and requires no authentication where the service is reachable over HTTP or HTTPS.
- Successful exploitation executes operating-system commands with the privileges of the TeamCity server process.
- JetBrains has issued fixed releases and a patch plugin, and reported no evidence of exploitation against TeamCity Cloud.
A critical vulnerability affecting every version of TeamCity On-Premises has exposed software build environments to unauthenticated remote command execution.
JetBrains said CVE-2026-63077 allows an attacker with HTTP or HTTPS access to a TeamCity server to bypass authentication and execute operating-system commands with the privileges of the server process. The flaw can be reached through the agent polling protocol without valid credentials.
Fixed versions, TeamCity 2025.11.7 and 2026.1.3, were released on 27 July. JetBrains has also provided a security patch plugin for installations running TeamCity 2017.1 or later where a full upgrade cannot be completed immediately. Its security advisory recommends upgrading because the maintenance releases include other security corrections beyond this vulnerability.
TeamCity Cloud customers do not need to take action because protective measures were applied to the hosted service. JetBrains said it found no evidence that cloud environments had been exploited through the flaw and was not aware of active exploitation when the advisory was published.
The vulnerability was privately reported on 10 July by researcher Antoni Tremblay. Public disclosure now compresses the patching window for organisations operating exposed servers, particularly because TeamCity often occupies a privileged position within software development and release infrastructure.
Build systems may hold access to source repositories, package registries, signing processes, deployment environments, test data, cloud accounts, and production services. Their agents can operate across separate networks or receive credentials that permit automated releases. Command execution on the central server can therefore extend beyond the host into the integrity of software produced through it.
Recovery extends into the delivery chain
Asset discovery should cover development, staging, disaster-recovery, laboratory, and abandoned instances rather than the principal production server alone. Systems left outside central administration can remain reachable long after their original project ends, while internet exposure may not be visible to the team responsible for software delivery.
Installing the update resolves the vulnerable code but does not establish whether an exposed server was previously accessed. TeamCity logs, operating-system activity, administrator changes, new users, altered projects, modified build steps, unexpected agents, and access to stored credentials should be reviewed across the period in which the server was vulnerable.
Where investigation cannot establish the integrity of builds created by an exposed system, organisations may need to reproduce artefacts from trusted source inside a clean environment. Signing credentials, deployment tokens, service accounts, registry secrets, and cloud keys available to the TeamCity process may also require rotation.
The affected platform illustrates the concentration of authority inside continuous integration and delivery systems. Development tooling may be managed as productivity infrastructure, yet it can read proprietary code, create executable software, sign artefacts, and deliver releases into production under the organisation’s identity.
That position becomes increasingly important under European product-security requirements. Organisations preparing for the Cyber Resilience Act will need development environments capable of supporting secure product life cycle obligations, reliable update mechanisms, vulnerability handling, and evidence that released software was produced through a trustworthy process.
JetBrains advises operators to place stronger access controls in front of internet-facing TeamCity systems, including a virtual private network or another protective layer. Network restrictions reduce exposure to future pre-authentication vulnerabilities, while dedicated hosts, segregated agents, short-lived credentials, minimal operating-system privileges, and artefact verification can limit the reach of a successful compromise.
Once a build server has been exposed to remote command execution, recovery cannot stop at the patched machine. Confidence must extend to the credentials it held, the agents it controlled, and the software it produced.
