CVE-2026-63077: No Auth, No Problem — TeamCity's CVSS 9.8 RCE

On July 28, JetBrains disclosed CVE-2026-63077, a critical unauthenticated remote code execution vulnerability in TeamCity On-Premises. CVSS score: 9.8. Every on-premises version is affected. No credentials required.

If you run a self-hosted TeamCity instance and it is reachable over the internet, you need to patch this today — not because it is actively being exploited at scale (JetBrains said it wasn't, as of Monday's advisory), but because the last comparable TeamCity flaw was weaponized inside 48 hours of disclosure. The attack surface here is nearly identical, and threat intelligence teams are already tracking exploitation attempts.

What the Flaw Actually Does

TeamCity uses an agent polling protocol — a persistent communication channel through which build agents check in with the central server for queued jobs. The vulnerability is a textbook insecure deserialization flaw (CWE-502): the server accepts serialized objects from the network on this endpoint and deserializes them without validation. An attacker who can reach the server over HTTP or HTTPS sends a crafted malicious payload to the exposed agent polling endpoint. No authentication. No prior foothold. The server executes arbitrary OS commands at the privilege level of the TeamCity process itself.

The CVSS vector spells out how clean the attack path is: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Network-accessible, low complexity, zero privileges, zero user interaction required — a profile purpose-built for automated mass scanning once a proof-of-concept circulates.

Why a CI/CD Server Is the Worst Place to Be Compromised

Attackers do not target TeamCity because they want to delay your deployments. They target it because it sits at the center of everything a development pipeline touches: source code repositories, deployment credentials, secrets embedded in build configurations, SSH private keys, API tokens, and cloud provider access keys. A server compromise lets an attacker silently modify build artifacts before they ship — which is how you end up distributing malware in your own software releases.

The 2023 SolarWinds supply-chain attack made this threat model mainstream. The mechanism here is structurally identical: compromise the build server, inject what you want, let the CI/CD pipeline carry it downstream. Affected data in a CVE-2026-63077 breach would include TeamCity project configurations and build history, stored credentials, and any secrets passed as environment variables during builds. Every downstream system that consumes those builds inherits the contamination.

History Suggests You Have Days, Not Weeks

JetBrains published the advisory on July 28 noting no confirmed active exploitation at time of release. That clock started the moment the advisory went public.

In March 2024, two TeamCity authentication bypass vulnerabilities — CVE-2024-27198 and CVE-2024-27199 — were disclosed on a Monday. By Wednesday, CISA and multiple threat intelligence firms confirmed active exploitation in the wild. Inside the first week, North Korean APT group Kimsuki was identified as one of the threat actors. APT29 and NOBELIUM had previously targeted an earlier TeamCity flaw (CVE-2023-42793) through similar channels. Ransomware campaigns followed rapidly: Jasmin ransomware, cryptominers, and remote access trojans were all deployed to compromised TeamCity servers within days of that 2024 disclosure.

CVE-2026-63077 is a different technical class — deserialization rather than auth bypass — but the exposure profile is nearly identical: internet-accessible CI/CD server, no credentials needed, complete server takeover as the outcome. IONIX's threat intelligence team reports it is already tracking active exploitation attempts as of this writing.

Who Is Exposed

Every TeamCity On-Premises instance on any version prior to 2025.11.7 (the 2025.11.x branch) or 2026.1.3 (the 2026.1.x branch) is vulnerable. There is no minimum version floor documented — if you are running on-premises TeamCity and have not updated to one of those releases, you are exposed.

TeamCity Cloud users are already protected. JetBrains pushed the fix to cloud instances before the public advisory, which is their standard practice for managed deployments.

The flaw was privately reported on July 10, 2026, by security researcher Antoni Tremblay through JetBrains' coordinated disclosure program. JetBrains had 18 days to prepare patches and a security plugin before going public, which means both remediation options are tested and ready.

How to Fix It

Upgrade. Update to TeamCity 2025.11.7 or 2026.1.3 — download links are in the JetBrains security advisory. That is the only complete remediation.

If an immediate upgrade is blocked by a change freeze or internal approval process, JetBrains has published a standalone security patch plugin compatible with TeamCity 2017.1 and later. Install it as a stopgap, but keep it exactly that — a stopgap, not a substitute for upgrading.

Regardless of when you patch, audit your exposure now:

• Is your TeamCity instance directly reachable from the public internet? If yes, restrict access to trusted IP ranges at the firewall level or put it behind a VPN. Build servers have no business being publicly routable.
• What OS account does the TeamCity server process run under? It should not be root or SYSTEM. Least-privilege accounts limit blast radius if something slips through in the future.
• What credentials and secrets are stored in your project build configurations? After patching, rotate anything sensitive that could have been accessible during any window you cannot fully audit.

The Bigger Pattern

CI/CD infrastructure has been a persistent high-value target for sophisticated attackers for a simple reason: it is the most privileged system in many environments, frequently provisioned at the network perimeter for webhook convenience, and often deprioritized during patch cycles because it is treated as internal tooling. CVE-2026-63077 is a reminder that the build pipeline deserves the same urgency as your edge-facing web servers — arguably more, since it controls what gets deployed to them.

At Falcon Internet, CI/CD security posture — including whether build servers are network-isolated and running under minimal privileges — is part of the infrastructure review we run for managed hosting customers. The pattern that keeps showing up in post-incident reviews: the attack did not start with the web server. It started with the system that deploys to it.