TeamCity CVE-2026-63077 RCE: Unauthenticated CI/CD Takeover
TeamCity CVE-2026-63077 RCE lets an unauthenticated attacker send a single crafted request to a TeamCity On-Premises server and execute operating system commands — no login, no valid session, no user interaction. CISA added it to the Known Exploited Vulnerabilities catalog on August 5 with a three-day remediation deadline, and exploitation is now active in the wild.
What Happened
TeamCity CVE-2026-63077 RCE traces back to a deserialization-of-untrusted-data flaw (CWE-502) in the agent polling protocol that TeamCity On-Premises uses to communicate with build agents. By sending crafted HTTP/S requests to this protocol, an attacker bypasses authentication entirely and executes arbitrary commands with the privileges of the TeamCity server process itself. JetBrains fixed the issue quietly on July 28 in TeamCity 2025.11.7 and 2026.1.3, and released a security patch plugin for organizations running version 2017.1 or later that cannot upgrade immediately. TeamCity Cloud customers were never affected and required no action.
The quiet fix did not stay quiet. On August 5, CISA moved its exploitation assessment for CVE-2026-63077 from “none” to “active” and added the flaw to its KEV catalog, rating it both automatable and capable of total technical impact — the highest severity combination CISA assigns. The federal remediation deadline was set for August 8, an unusually short three-day window under Binding Operational Directive 26-04, signalling that CISA considers active mass exploitation likely rather than theoretical.
Why It Matters
A compromised TeamCity server is not just one more breached host — it is a compromised software factory. Attackers with server-process privileges can read stored credentials for every connected repository, cloud account, and artifact registry; tamper with build configurations; and inject malicious code into build artifacts before they ship. For any organization that has not fully separated build-server credentials from production access, a TeamCity breach converts directly into a downstream supply-chain incident affecting every customer or internal team that consumes those builds.
TeamCity On-Premises remains a common choice for German engineering, manufacturing, and automotive software teams that keep CI/CD infrastructure on-premises for data residency or contractual reasons — exactly the population least likely to have already migrated to TeamCity Cloud, and therefore fully exposed to this flaw. This is the fourth self-hosted developer platform DIESEC has tracked as a 2026 exploitation target, following Gogs/Gitea (May 29), a second Gitea flaw (July 14), and GitLab’s “Oj Spill” disclosure (July 28) — a pattern of self-hosted developer infrastructure being patched quietly weeks before exploitation goes live, often without a clearly assigned patch-management owner.
What You Should Do Now
- Patch immediately: Upgrade TeamCity On-Premises to 2026.1.3 (build 222742) or 2025.11.7 (build 208264). If an immediate upgrade is not possible, install JetBrains’ dedicated security patch plugin, available for TeamCity 2017.1 and later.
- Verify your version: Check the TeamCity server’s About page or build number against the fixed builds above. Any version prior to these is vulnerable regardless of how recently it was installed.
- Mitigate if you cannot patch today: JetBrains recommends restricting network access to the TeamCity server to trusted networks only — require a VPN connection for any internet-facing instance, and remove direct internet exposure of the agent polling endpoint where possible.
- Monitor: Review TeamCity server logs for unexpected requests to the agent polling protocol, unrecognized build configuration changes, and any outbound connections from the TeamCity host that do not match known artifact registries or repositories. Rotate credentials stored in TeamCity (repository tokens, cloud provider keys, registry credentials) if the server was internet-facing and unpatched at any point since July 28.
DIESEC Perspective
We keep seeing the same failure mode across 2026: self-hosted developer tools — Gitea, GitLab, now TeamCity — get a quiet vendor patch, and the actual risk window opens weeks later when a researcher or attacker demonstrates working exploitation. The gap is rarely technical; it’s organizational. Nobody in most DACH Mittelstand engineering teams owns “patch the CI/CD server” as a named responsibility the way “patch the domain controller” is owned. CVE-2026-63077 is a good forcing function to fix that gap, not just this one server.
Not sure whether your CI/CD infrastructure has this kind of ownership gap? Contact DIESEC for a rapid build-pipeline exposure assessment and credential-hygiene review.
Sources: JetBrains Blog | The Hacker News
Published: 2026-08-10 | Category: Vulnerabilities & Patches | ~4 min read
