CVE-2026-63077 (CVSS 9.8): Unauthenticated RCE in JetBrains TeamCity — Your CI/CD Pipeline Is One HTTP Request Away from Compromise

Three days ago, JetBrains quietly published what could become the supply-chain security crisis of the quarter. CVE-2026-63077 — a CVSS 9.8 Critical unauthenticated remote code execution flaw — sits inside every on-premises installation of TeamCity, the CI/CD platform that builds, tests, and deploys software for tens of thousands of organisations worldwide. An attacker anywhere on the internet, with zero credentials, can send a single crafted request to your TeamCity server and gain the ability to run arbitrary operating system commands as the TeamCity service account. Your build pipelines, your stored secrets, your deployment keys — all of it is one HTTP request away from being owned.

If your team uses TeamCity and you have not yet updated to version 2025.11.7 or 2026.1.3, or applied the security patch plugin, this post is the most important thing you will read today.

What Is CVE-2026-63077?

CVE-2026-63077 was privately reported to JetBrains on 10 July 2026 by security researcher Antoni Tremblay through the company’s coordinated disclosure process. JetBrains published its official security advisory on 27 July 2026, alongside patched releases and a standalone plugin for organisations that cannot upgrade immediately.

The vulnerability is rooted in deserialization of untrusted data within TeamCity’s agent polling protocol — the communication channel that TeamCity build agents use to check in with the central server for new build tasks. Because this protocol was not designed with the assumption that hostile, unauthenticated clients would be making requests, it failed to enforce authentication before processing the incoming payload. A malformed request exploiting this path allows an attacker to bypass all authentication checks and execute arbitrary OS commands with the privileges of the TeamCity server process.

Rapid7’s Exposure Team, which integrated detection into InsightVM, Nexpose, and Exposure Command on 28 July, classifies the attack vector as network-accessible, requiring no privileges and no user interaction. The CVSS 9.8 score reflects precisely that: near-maximum severity, with the only mitigating factor being that physical access is not required.

How the Attack Works: Inside the Agent Polling Protocol

To understand the risk, it helps to understand TeamCity’s distributed architecture. A typical enterprise TeamCity deployment consists of:

• A central server that stores configurations, credentials, build history, and triggers pipelines.
• Multiple build agents — separate machines or containers — that poll the server over HTTP(S) for jobs to execute.

The agent polling protocol is, by design, reachable from any machine that can connect to the TeamCity server’s HTTP(S) port. That includes internet-exposed servers. CVE-2026-63077 allows an attacker to impersonate a build agent’s initial handshake request, slipping a malicious serialised payload into the interaction before any authentication gate is enforced.

Once the payload is deserialised by the server, the attacker achieves code execution at the privilege level of the TeamCity service account — which, in many real-world deployments, runs with broad OS permissions or even SYSTEM/root. The attacker can then:

• Exfiltrate stored credentials, API tokens, SSH keys, and deployment secrets cached in TeamCity’s configuration.
• Modify build scripts and pipeline definitions to inject malicious code into software artifacts your organisation ships to customers.
• Use the TeamCity server as a beachhead for lateral movement into development, staging, or production environments.
• Establish persistence via backdoored build plugins or scheduled tasks.

It is worth emphasising: an attacker does not need an account. They do not need to know any employee’s credentials. They need only an HTTP connection to your TeamCity server.

Why CI/CD Servers Are Crown Jewels for Attackers

Build servers sit at the intersection of your source code, your cloud credentials, and your production environment. Compromising a CI/CD platform is not a lateral movement step — it is frequently the goal. Nation-state actors and ransomware operators have long recognised that a single foothold in a build server can cascade into a full supply-chain compromise, poisoning software before it ever reaches end users.

This is not theoretical. In early 2024, the BianLian ransomware group actively exploited CVE-2024-27198, a predecessor TeamCity vulnerability, to gain initial access to enterprise environments. North Korean threat actors linked to the Kimsuky cluster also targeted the same CVE. In both cases, the playbook was identical: exploit TeamCity, steal credentials, move laterally, and either ransom the organisation or conduct long-term espionage.

CVE-2026-63077 is, by CVSS score, equally critical to those earlier flaws. The absence of confirmed active exploitation today does not mean tomorrow will be the same. History strongly suggests a race has already begun between defenders patching and attackers weaponising.

Consider what is at stake for a typical Indian enterprise with 300–5,000 employees:

Asset at Risk	Potential Impact
Cloud IAM credentials in build env	Full cloud environment takeover
SSH deploy keys to production servers	Direct access to production infrastructure
Code signing certificates	Malware signed with your trusted certificate
Build artifacts and release packages	Software supply-chain poisoning for customers
Source code repositories	Intellectual property theft or sabotage

It is also worth noting that this week’s Gitea RCE (CVE-2026-60004) demonstrated that attackers are specifically hunting DevOps infrastructure. TeamCity and Gitea often sit together in the same development environment — a double exposure that should alarm any CISO.

What You Should Do Right Now

As a cybersecurity consultant who has spent three decades hardening enterprise networks — including the FortiGate and zero-trust architectures that protect NOC/SOC environments across India — my recommendation is unambiguous: treat this as a P1 incident response, not a routine patch.

Here is the prioritised action list:

1. Identify every TeamCity On-Premises instance in your environment. Check shadow IT: development teams sometimes spin up build servers that never appear on the official asset inventory.
2. Upgrade immediately to TeamCity 2025.11.7 or 2026.1.3. If your version is 2024.03 or later, JetBrains’ security patch plugin auto-downloads with an admin notification — verify it applied.
3. If you cannot upgrade immediately, install the standalone security patch plugin (supported on 2017.1+). Download it directly from the JetBrains advisory page.
4. Restrict network access. Your TeamCity server should never be internet-accessible without a VPN or zero-trust network access (ZTNA) gateway in front of it. If it is, treat the server as potentially compromised and begin incident response procedures immediately.
5. Audit stored credentials. Rotate all API tokens, SSH keys, cloud IAM credentials, and secrets stored in TeamCity’s configuration — regardless of whether exploitation is confirmed. If the window existed, assume theft is possible.
6. Review build history. Look for unexpected build steps, new plugins, or configuration changes in the past 48–72 hours. Attackers who gained early access may have already left persistence mechanisms.
7. Enable SIEM alerting for anomalous TeamCity server behaviour: unexpected outbound connections, new administrator accounts, or unusual build agent registrations.

The Zero-Trust Lens: Why Your Build Server Should Never Be on the Open Internet

CVE-2026-63077 is a technical vulnerability, but the organisational failure it exposes is architectural. A TeamCity server listening on a public IP — even behind a firewall with port 8111 open — is an unacceptable risk posture. The zero-trust principle of never trust, always verify applies as much to your CI/CD infrastructure as to your user access policies.

Best-practice architecture for TeamCity in a zero-trust environment:

• Segment the build network. Build servers belong in their own VLAN or micro-segment with deny-all inbound from the internet and explicit allow-lists for build agents.
• Require ZTNA or VPN for any developer or build agent that needs to reach the TeamCity server. This eliminates the attack surface CVE-2026-63077 exploits entirely.
• Use short-lived, scoped credentials in build pipelines. Never store long-lived cloud credentials in TeamCity’s configuration store; use dynamic secrets via HashiCorp Vault, AWS IAM Roles, or Azure Managed Identities instead.
• Monitor with a dedicated SOC rule for unexpected TeamCity API calls, especially those matching the agent polling protocol pattern from non-registered agent IPs.

For organisations already running FortiGate NGFW, a temporary IPS signature blocking the malformed agent polling request pattern can provide a defence-in-depth layer while patching proceeds — but do not let that become a reason to delay the patch itself.

Frequently Asked Questions

Does this affect TeamCity Cloud?

No. CVE-2026-63077 affects only TeamCity On-Premises deployments. JetBrains has confirmed that TeamCity Cloud is not vulnerable — the cloud infrastructure was patched transparently by JetBrains before the advisory was published.

Is there a public proof-of-concept exploit available?

As of 30 July 2026, no public proof-of-concept (PoC) exploit code has been published on GitHub or known exploit repositories. However, the vulnerability’s mechanism — unauthenticated deserialization via the agent polling protocol — is well understood, and the technical bar for producing a working exploit is not high for experienced threat actors. The absence of a public PoC today should not be interpreted as safety; it simply means the exploitation window is narrower right now than it will be once PoC code circulates.

What versions of TeamCity are affected?

All versions of JetBrains TeamCity On-Premises prior to 2025.11.7 and 2026.1.3 are affected. JetBrains has not published a specific “first affected version” because the agent polling protocol has been present throughout the product’s lifespan. If you are running any on-premises TeamCity version and have not yet applied the patch or the security plugin, assume you are vulnerable.

How quickly could active exploitation begin after disclosure?

Based on the track record of previous critical TeamCity CVEs, very quickly. CVE-2024-27198 (CVSS 9.8) saw ransomware operators begin exploitation within 72 hours of public disclosure. Nation-state groups were observed targeting TeamCity even before public PoC code appeared. With CVE-2026-63077 now public for three days, the window for comfortable pre-exploitation patching is closing fast. Every hour of delay increases the risk of being caught in the initial wave of opportunistic scanning.

---