JetBrains TeamCity RCE Puts Self-Hosted CI/CD Servers on an Urgent Patch Clock

JetBrains has released fixes for CVE-2026-63077, a critical unauthenticated remote code execution vulnerability affecting TeamCity On-Premises. The issue allows an attacker with HTTP or HTTPS access to a vulnerable TeamCity server to bypass authentication checks and execute operating system commands with the privileges of the TeamCity server process.

The fix is available in TeamCity 2025.11.7 and TeamCity 2026.1.3. JetBrains has also released a security patch plugin for customers who cannot immediately upgrade and says TeamCity Cloud customers do not need to take action because the cloud environment has already received the necessary protections.

There is one important nuance: JetBrains said it was not aware of active exploitation at the time of publication. That should not make defenders comfortable. TeamCity is not just another web application. It is a CI/CD control plane that can touch source code, build artifacts, deployment secrets, signing workflows, internal package feeds, test environments, and production release pipelines. A pre-authentication RCE in that layer can become a software delivery and supply chain incident very quickly.

What happened

On July 27, 2026, JetBrains published a security advisory for CVE-2026-63077. The company said the flaw affects all TeamCity On-Premises versions and was privately reported on July 10, 2026 by security researcher Antoni Tremblay under coordinated disclosure.

NVD lists the vulnerability as an unauthenticated RCE in JetBrains TeamCity before versions 2026.1.3 and 2025.11.7 via the TeamCity agent polling protocol. The CNA score from JetBrains is CVSS 9.8 Critical, with network attack vector, low attack complexity, no privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

JetBrains says exploitation requires the vulnerable TeamCity server to be reachable over HTTP(S). If exploited, the attacker can run commands as the TeamCity server process. Depending on how the server was deployed, that can expose TeamCity data, configuration, stored credentials, build history, plugin state, and the integrity of downstream build and deployment workflows.

Why this matters beyond one server

TeamCity sits in a dangerous trust position. It coordinates build agents, pulls code, runs scripts, stores project configuration, manages integrations, and often has access to credentials that ordinary application servers should never see.

That makes the blast radius different from a typical single-host vulnerability. A compromised TeamCity server may let an attacker:

• read secrets used by build and deployment jobs,
• tamper with build steps or artifact output,
• push malicious updates into downstream environments,
• modify project configuration or plugin behavior,
• reach connected build agents,
• harvest tokens for source control, container registries, cloud platforms, or internal package repositories,
• create a trusted path for later lateral movement.

The risk is highest where TeamCity is internet-facing, reachable from broad internal networks, or exposed through a VPN that many users and contractors can access. Even if the TeamCity login page looks harmless, JetBrains explicitly warns that exposing the login screen or REST API can give attackers useful entry points when newly disclosed vulnerabilities appear.

The agent polling protocol detail

The public technical detail is limited, but the available advisories identify the TeamCity agent polling protocol as the exploitation path. In normal operation, build agents need to communicate with the TeamCity server to receive work and report status. That communication path is part of the core trust model for a CI/CD system.

For defenders, the protocol name is less important than the exposure model. If an unauthenticated attacker can reach the vulnerable server over HTTP(S), the patch should be treated as urgent. Network filtering, VPN enforcement, and additional access controls reduce risk, but they are not a substitute for upgrading or applying JetBrains' patch plugin.

This is also a reminder that CI/CD systems have many interfaces that are not obvious to business users. Web UI, REST APIs, plugin endpoints, agent communication paths, artifact storage, and integrations can all become security-relevant attack surface.

What defenders should do now

1. Identify every TeamCity On-Premises server

Start with inventory, not assumptions. Look for self-hosted TeamCity instances in production, engineering networks, lab environments, cloud accounts, developer infrastructure, and legacy build systems. Include servers that are not internet-facing but are reachable from broad corporate networks or VPN pools.

For each instance, record:

• version,
• exposure path,
• authentication boundary,
• connected build agents,
• stored credential types,
• source-control integrations,
• deployment targets,
• plugin inventory,
• last backup time,
• owner and maintenance window.

2. Upgrade to 2025.11.7 or 2026.1.3

The primary fix is to upgrade the TeamCity server to 2025.11.7 or 2026.1.3. If an immediate version upgrade is not possible, apply JetBrains' security patch plugin for supported older versions.

JetBrains says the patch plugin covers TeamCity 2017.1 and newer. Servers running TeamCity 2017.1 to 2018.1 require a restart after plugin installation; versions from 2018.2 onward can enable the plugin without restarting the server.

Treat the patch plugin as a bridge, not a long-term maintenance strategy. JetBrains notes that it addresses this specific CVE only, while full upgrades include broader security updates.

3. Restrict network access

Limit TeamCity access to trusted networks wherever possible. Internet-facing TeamCity servers should require VPN access or another access-control layer in front of the application.

This is especially important because TeamCity has a history of being attractive to state-sponsored groups and ransomware affiliates. Attackers like CI/CD platforms because compromise can give them a route into source code, secrets, build infrastructure, and production release paths.

4. Run TeamCity with minimum privileges

Review the operating-system account used by the TeamCity server process. If the process runs with broad local privileges, a successful exploit becomes more damaging.

The TeamCity server should not run as root or with unnecessary administrative rights. It should also live on a dedicated host separate from build agents where possible, so server compromise does not automatically collapse the rest of the build environment.

5. Check for signs of compromise

Even though JetBrains said it was not aware of active exploitation when the advisory was published, defenders should still review exposed or high-value servers. The more reachable the instance, the stronger the case for incident response validation.

Useful checks include:

• unexpected administrative users or API tokens,
• modified build steps,
• new or changed plugins,
• suspicious agent registration or agent behavior,
• unfamiliar project configuration changes,
• new scheduled jobs or command execution patterns,
• unusual outbound network activity from the TeamCity host,
• access from unfamiliar IP addresses,
• changed credentials in integrations,
• modified artifacts or unexpected releases.

If the server was internet-facing before the fix, assume patching is only the first step. Review whether the system was touched during the exposure window.

Strategic takeaway

CVE-2026-63077 is a straightforward patch-now vulnerability with a larger operational lesson. CI/CD servers are privileged coordination systems, not ordinary admin portals. They connect code, credentials, automation, artifacts, and deployment authority.

For TeamCity On-Premises customers, the immediate response is clear:

• upgrade to TeamCity 2025.11.7 or 2026.1.3,
• apply the security patch plugin only when upgrade timing blocks the full fix,
• restrict HTTP(S) access to trusted networks,
• run the server with minimum required privileges,
• separate the TeamCity server from build agents,
• review exposed systems for suspicious changes.

There may be no confirmed exploitation yet, but the defender window is open now. Once a critical pre-authentication CI/CD RCE is public, the safest assumption is that attackers will test reachable servers quickly.

What is CVE-2026-63077?

CVE-2026-63077 is a critical unauthenticated RCE vulnerability in JetBrains TeamCity On-Premises. It can allow an attacker with HTTP(S) access to execute operating-system commands as the TeamCity server process.

Which TeamCity versions fix it?

JetBrains fixed the issue in TeamCity 2025.11.7 and 2026.1.3.

Are TeamCity Cloud customers affected?

JetBrains says TeamCity Cloud customers do not need to take action because the necessary measures have already been applied.

Is there active exploitation?

JetBrains said it was not aware of active exploitation at the time it published the advisory. That status can change, so exposed self-hosted servers should still be patched and reviewed urgently.

What if we cannot upgrade immediately?

JetBrains released a security patch plugin for TeamCity 2017.1 and newer. Use it as a temporary control, then plan a full upgrade.

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. CVE-2026-63077: Deserialization of Untrusted Data
4. JetBrains fixes critical unauthenticated RCE in TeamCity On-Premises (CVE-2026-63077)