An Authentication Bypass With Maximum Consequences

JetBrains has shipped an emergency fix for a critical flaw in TeamCity On-Premises that lets an outsider seize control of a build server without ever logging in. Tracked as CVE-2026-63077, the bug sits in the way TeamCity’s build agents check in with the central server, and it requires nothing more than network access to a vulnerable instance — no stolen password, no valid session token, no insider help.

The weakness lives in the agent polling protocol, the mechanism TeamCity uses to let distributed build agents fetch new instructions from the server. Because that channel wasn’t properly gated behind authentication, a remote attacker can abuse it to run arbitrary operating system commands with the same privileges as the TeamCity server process itself. In practice, that means full control over whatever machine is hosting the CI/CD pipeline.

Why a Build Server Compromise Is Worse Than It Sounds

TeamCity isn’t just another application sitting on a network; for many engineering teams it’s the machine that assembles, signs, and ships production software. An attacker who lands inside it inherits a front-row seat to everything that passes through the pipeline, including:

• Stored credentials and API keys used to deploy to cloud environments
• Configuration files and project secrets tied to internal systems
• Build artifacts that can be quietly modified before release
• The ability to inject malicious code directly into downstream software

That last point is what makes unauthenticated build-server bugs so dangerous at scale — a compromised CI/CD system can become a distribution point, pushing tampered code to every customer or internal team that consumes its output. It’s the same category of risk that has made supply chain attacks such a persistent theme in enterprise security over the past few years.

Responsible Disclosure and a Fast Turnaround

The flaw was privately reported to JetBrains on July 10, 2026 by security researcher Antoni Tremblay through the company’s coordinated disclosure channel. JetBrains moved quickly, shipping fixes in TeamCity versions 2025.11.7 and 2026.1.3. The company says it has no evidence of active exploitation so far, and that TeamCity Cloud customers were already protected and require no action.

That’s reassuring, but it isn’t a reason for on-premises administrators to relax. Unauthenticated remote code execution bugs in widely deployed developer tools tend to attract attention from opportunistic scanners within days of disclosure, and TeamCity has been a favored target for ransomware affiliates in past incidents.

What Administrators Should Do Now

Organizations running TeamCity On-Premises should treat this as a same-day patching priority. JetBrains recommends upgrading directly to a fixed version wherever possible, using the platform’s built-in automatic update feature if it’s enabled. For teams that can’t upgrade immediately, JetBrains has published a dedicated security patch plugin covering versions as far back as 2017.1.

A few operational notes worth flagging for admins working through remediation:

• Servers on TeamCity 2017.1 through 2018.1 will need a restart after installing the patch plugin; 2018.2 and later can apply it without downtime.
• The patch plugin is explicitly described as a stopgap — a full version upgrade is still needed to pick up other security fixes bundled into the newer releases.
• Security update status can be checked from the Administration menu under Updates and Available Security Updates, and TeamCity 2024.03 and later can fetch patch plugins automatically.

Beyond patching, JetBrains is urging longer-term hardening steps: restrict TeamCity access to trusted networks rather than exposing it directly to the internet, place any internet-facing instance behind a VPN or equivalent access control layer, run the TeamCity service with the minimum operating system privileges it needs, and separate the TeamCity server from its build agents so a breach of one doesn’t automatically hand over the other.

The Bigger Pattern

This isn’t the first time a critical flaw has surfaced in TeamCity, and it won’t be the last time a CI/CD platform becomes the entry point for a much larger compromise. Build systems occupy a privileged position by design — they need broad access to code, credentials, and deployment infrastructure to do their job. That same access is exactly what makes them worth an attacker’s time. Teams that haven’t already inventoried which of their DevOps tools face the open internet should treat this disclosure as a prompt to do so, regardless of whether TeamCity is part of their stack.