# TeamCity's Build Pipeline Is an Open Door — Again
JetBrains has patched a critical unauthenticated remote code execution vulnerability in TeamCity. If that sentence gives you déjà vu, it should.
CVE-2026-63077 lives in TeamCity's agent polling protocol — the channel that build agents use to check in with the central server and pull job assignments. An attacker without any credentials can speak that protocol, and somewhere in how TeamCity handles those requests, arbitrary code execution becomes possible. The full technical details haven't dropped yet, but "unauthenticated RCE via build agent protocol" is a sentence that should make every DevOps team running an on-prem TeamCity instance stop what they're doing.
## What the Agent Polling Protocol Actually Is
If you don't work with TeamCity daily, a quick orientation matters here. TeamCity is a CI/CD platform — it runs your builds, runs your tests, and frequently holds the keys to your artifact repositories, cloud deployments, and code signing infrastructure. The "agents" are the worker nodes that actually execute build steps; they poll the central server on a scheduled basis asking for work.
This polling relationship is by design. Agents initiate outbound connections to the server, which simplifies firewall rules and lets distributed teams add build capacity without complex inbound networking. It's a reasonable architecture — but it also means the server has to accept and parse messages from any machine that claims to be an agent. If the parsing is broken or the authentication is missing, you have a problem. You now have CVE-2026-63077.
What makes this especially dangerous is what the TeamCity server touches. In a mature CI/CD setup, that machine typically has access to source repositories, production deployment credentials, container registries, and sometimes code signing keys. Getting code execution on the TeamCity server isn't a foothold — it's a master key.
## The Pattern This Fits
Let's be direct: this is not TeamCity's first rodeo with critical vulnerabilities that get actively exploited before organizations patch.
In late 2023, CVE-2023-42793 — another authentication bypass in TeamCity — became one of the most significant software supply chain attack vectors of that year. Russian SVR operators (APT29, Cozy Bear, pick your label) exploited it at scale to compromise software vendor networks. The CISA, NSA, FBI, and their Five Eyes counterparts issued a joint advisory. Thousands of TeamCity instances were internet-exposed and unpatched when exploitation started, and the attackers were methodical about leveraging the access: persistence, lateral movement, credential harvesting.
That was a 9.8 CVSS authentication bypass. CVE-2026-63077 is described as critical, exploitable without authentication, and involving code execution. It sits in the same threat class.
The uncomfortable reality is that CI/CD infrastructure has been a priority target for sophisticated threat actors for years now, and the attacker interest isn't declining. Why? Because compromising the build system is more efficient than compromising every target individually. One foothold in a software vendor's TeamCity server can yield access to dozens of downstream customers, depending on the vendor's delivery model.
## Who Is Actually Exposed
JetBrains offers TeamCity both as a cloud-hosted service and as an on-premises deployment. The cloud version is typically patched by JetBrains before advisories go public — on-prem customers are responsible for their own patching cadence.
On-prem TeamCity instances are common in:
These are also organizations that tend to have slower patch cycles, more complex change management processes, and — in the case of government contractors — the kind of access that makes them interesting to nation-state actors.
If you're running TeamCity on-prem and your instance is internet-facing, you need to treat this as an emergency patch. If it's internal-only, you should still treat it as urgent — "unauthenticated" means any internal user or any machine with network access to the TeamCity server can trigger the exploit.
## What to Do Right Now
The short list, in order of priority:
Patch immediately. JetBrains has issued a fix. There is no good reason to wait on this one given the vulnerability class.
Check exposure. Run a quick scan or review your firewall rules. Is your TeamCity server reachable from the internet? From partner networks? From the broader corporate network without segmentation? Each of those answers changes your risk profile.
Review recent agent activity. If you have logs, look at agent connections from the past few weeks. Unknown agents, unusual polling patterns, or connections from unexpected IP ranges are worth investigating now.
Rotate credentials the server touches. If exploitation occurred before patching — and you may not be able to rule that out — the credentials stored in TeamCity (cloud provider tokens, registry credentials, deployment keys, signing certificates) should be rotated. The server likely has access to more sensitive material than most organizations track carefully.
Segment if you can't patch immediately. If patching requires a change management process that will take days, restrict network access to the TeamCity server as a stop-gap.
---
## HackWire Analysis
The detail that deserves more attention than it's getting is the specific attack surface: the agent polling protocol.
Most CI/CD security conversation focuses on the obvious vectors — misconfigured pipelines, secrets in environment variables, insecure build scripts. The server-to-agent communication layer gets far less scrutiny, even though it's a rich target. Build agents often run with elevated privileges, sometimes on the same hosts as production infrastructure, sometimes with unfiltered outbound internet access to pull dependencies. An attacker who can interact with the agent polling mechanism — whether by impersonating an agent or by sending malformed polling requests — is in an interesting position even before we get to code execution.
What worries me more broadly is organizational posture. After the 2023 TeamCity exploitation campaign, JetBrains improved their security engineering and patching processes. Organizations, in aggregate, did not meaningfully improve their TeamCity patch cadence. The CISA advisory generated coverage, some organizations patched, many didn't. We are almost certainly in the same situation now: a critical vulnerability, a patch available, and a distribution of patch timing that leaves a meaningful percentage of the population exposed for weeks or months.
The software supply chain attack surface isn't theoretical. It's been the preferred vector for some of the most consequential intrusions of the past five years. TeamCity is a high-value target because the organizations that run it on-prem tend to be exactly the organizations sophisticated actors want access to — regulated industries, defense contractors, enterprise software vendors. Patching TeamCity quickly isn't routine hygiene. It's direct mitigation against a known and active threat category.
The organizations most likely to be slow on this patch are also the organizations most likely to be on someone's target list.
— HackWire Editorial
---
## Related Coverage