A single, unauthenticated flaw in JetBrains TeamCity On-Premises now sits at the center of a question every security leader has been asking since the last wave of software supply chain attacks: what happens when the system that builds your software becomes the easiest way in. CVE-2026-63077, disclosed by JetBrains on July 27, 2026, lets a remote attacker with nothing more than network access to a TeamCity server bypass authentication entirely and run operating system commands with the privileges of the TeamCity process itself.
What JetBrains disclosed
According to JetBrains’ own advisory, the flaw is a deserialization of untrusted data issue in the TeamCity agent polling protocol, the channel build agents use to check in with the central server. An attacker who can reach that protocol over HTTP or HTTPS does not need a username, a password, or a session token. JetBrains states plainly that “an unauthenticated attacker with HTTP(S) access to a TeamCity server” can “bypass authentication checks and execute arbitrary operating system commands,” with those commands running under the same privileges as the TeamCity server process.
Security vendor Rapid7, which analyzed the flaw for its customers, rates it a maximum-range CVSS 9.8, the ceiling reserved for bugs that require no privileges, no user interaction, and no special access to trigger. JetBrains says all versions of TeamCity On-Premises are affected. TeamCity Cloud customers are not, since JetBrains manages network exposure on that tier directly.
The flaw was reported responsibly. Researcher Antoni Tremblay privately disclosed it to JetBrains on July 10, 2026, giving the vendor more than two weeks to prepare fixes before the public advisory went out. As of the advisory’s publication, JetBrains says it has no evidence of active exploitation. That window will not stay open long. Unauthenticated, pre-auth remote code execution bugs in widely deployed developer infrastructure are reliably weaponized within days of disclosure, and TeamCity servers are a known, high-value target because of what they hold.
Why a build server is worth more than the software it builds
TeamCity is not an edge appliance or a marketing tool. It is CI/CD infrastructure: the system that pulls source code, injects deployment credentials, signs artifacts, and pushes finished builds into production. A TeamCity server typically has the exact secrets an attacker wants, cloud API keys, source repository tokens, artifact-signing keys, and connections into the environments that receive its builds. JetBrains’ own advisory names the risk directly, warning that a successful attacker “can read stored credentials” and “compromise CI/CD pipeline integrity.”
That second phrase is the one that should get a CISO’s attention. Compromising pipeline integrity does not just mean stealing secrets from one server. It means an attacker sitting inside the process that ships code to every downstream system that trusts a TeamCity build. That is the same structural risk that has driven a broader industry push toward hardening open source and internal build ecosystems, from GitHub and PyPI’s move to make publishing delays and provenance checks the default for package ecosystems trying to blunt supply chain poisoning. A CI/CD server with an unauthenticated RCE flaw is the same problem from the other direction: instead of a poisoned dependency flowing into a pipeline, the pipeline itself becomes the entry point.
What defenders should check first
JetBrains’ guidance is specific and actionable. Organizations running TeamCity On-Premises should:
- Upgrade to TeamCity 2025.11.7 or 2026.1.3, the two versions JetBrains shipped with the fix.
- If an immediate full upgrade is not possible, install JetBrains’ security patch plugin, available for TeamCity 2017.1 and later, which addresses CVE-2026-63077 specifically without a full version migration.
- Restrict network access to TeamCity servers. JetBrains recommends requiring VPN access for any internet-facing instance and limiting reachability to trusted networks only.
- Separate the TeamCity server from build agents on dedicated hosts, reducing the blast radius if the server process is compromised.
Because the vulnerable component is the agent polling protocol, network segmentation is not a cosmetic control here. An attacker who cannot reach the TeamCity server’s HTTP(S) listener cannot exploit CVE-2026-63077 at all, regardless of patch status. Organizations that cannot patch immediately should treat network isolation as the interim control, not an afterthought.
What it means for the security leader
Pre-auth RCE in developer infrastructure forces a different kind of triage than a typical application vulnerability. The question is not just “did we patch,” it is “what could an attacker have reached if they had gotten in the day this was disclosed.” Security teams should audit which secrets their TeamCity instances hold, rotate anything that a compromised server process could have exposed, and review build logs for the period since the agent polling protocol issue could plausibly have been exploited, even absent a confirmed incident.
The broader signal is one CISOs have seen before and will see again: internal developer tooling, not just customer-facing applications, is now squarely inside the attack surface that gets prioritized. A build server sitting behind the corporate firewall used to feel low-risk by virtue of being internal. An unauthenticated, network-reachable RCE flaw erases that assumption. Any system that touches source code, secrets, or deployment pipelines deserves the same exposure review as an internet-facing web application, because functionally, for an attacker, that is exactly what it is.
What to do now
Security teams running TeamCity On-Premises should treat this as an emergency-patch event, not a routine update cycle: confirm version, patch or apply the interim plugin, verify network exposure is limited to trusted access paths, and rotate credentials the server could have exposed. Teams that have already patched should still check logs going back to July 10, when the flaw was first reported to JetBrains, in case exploitation began before the public advisory closed the information gap.
Source: JetBrains
