# Your Build Server Is Someone Else's Backdoor: Attackers Are Already Exploiting CVE-2026-63077 in TeamCity


JetBrains TeamCity is under active exploitation again. CVE-2026-63077, a critical unauthenticated remote code execution flaw, is now being weaponized in the wild — and if your CI/CD infrastructure isn't patched, you aren't dealing with a theoretical risk anymore.


For the third time in three years, a TeamCity vulnerability has crossed from "patch it soon" to "you're being hit right now."


---


## What the Bug Actually Does


The vulnerability is as bad as RCE gets: no credentials required, no user interaction needed, just network access to a vulnerable TeamCity server and an attacker walks in. CVE-2026-63077 carries a critical severity rating, and based on how this class of flaw works in practice, exploitation likely allows an attacker to execute arbitrary commands under the context of the TeamCity process — which typically runs with elevated privileges and rich access to connected resources.


JetBrains hasn't published full technical details of the root cause yet, which is standard procedure to give administrators time to patch before a detailed proof-of-concept circulates freely. But given the exploit is already active in the wild, that window is closing fast.


If you run TeamCity on-premises and haven't applied the fix, assume you are a target.


---


## The Reason TeamCity Keeps Getting Hit


It's not random that TeamCity shows up on this list repeatedly. The platform is CI/CD infrastructure — build servers, automated pipelines, the machinery that turns source code into shipped software. That position in the development lifecycle makes it extraordinarily valuable to attackers.


Think about what a compromised TeamCity server can reach:


  • Source code repositories — the actual codebases of every project running through the pipeline
  • Build secrets and API tokens — credentials injected at build time for cloud deployments, container registries, and third-party services
  • Artifact repositories — the compiled software itself, which can be tampered with before it ships
  • Production deployment pipelines — some configurations give TeamCity direct deploy access to staging and production environments

  • This isn't a lateral movement story. Owning a CI/CD server is frequently a direct path to the most sensitive parts of an organization — or, in a supply chain attack, to the organization's customers.


    The prior playbook is well-documented. In 2023, CVE-2023-42793 was exploited by Lazarus Group (North Korea's state-sponsored hackers) to breach software companies and conduct supply chain intrusions. In early 2024, CVE-2024-27198 was seized on by multiple threat actors within days of disclosure — ransomware operators, espionage groups, and opportunistic attackers all piling in simultaneously. CISA issued joint advisories with the FBI on both.


    CVE-2026-63077 fits the same pattern. Unauthenticated RCE in TeamCity isn't a new category of risk — it's a recurring one.


    ---


    ## Who's Exposed


    TeamCity is widely deployed in enterprise environments. JetBrains claims tens of thousands of organizations run it, spanning software vendors, financial institutions, healthcare systems, manufacturing companies, and government agencies.


    The highest-risk populations right now:


    Software vendors and SaaS companies. A compromised build pipeline here can poison artifacts that ship to customers. This is the supply chain attack vector — and it's been used successfully before.


    Financial sector DevOps teams. Banks and fintechs that run internal TeamCity installations often have deployment pipelines connected to cloud environments with elevated permissions. An attacker who can execute code on the build server may be steps away from production infrastructure.


    Organizations with internet-exposed TeamCity instances. On-premises deployments that are accessible directly from the internet — without VPN, IP restrictions, or reverse proxy filtering — face the highest immediate risk. Shodan and similar scanners will have indexed these.


    Cloud-hosted TeamCity that lacks network controls. Even cloud deployments can be misconfigured with overly permissive network access.


    TeamCity Cloud (JetBrains' managed offering) has already been patched — the active risk is on-premises customers who haven't updated.


    ---


    ## What to Do Right Now


    The remediation hierarchy here isn't complicated, but urgency matters.


    Patch immediately. Apply the fix JetBrains has released. If your organization has a change-freeze or standard patch cycle, this overrides it — active exploitation of unauthenticated RCE is a break-glass moment.


    Audit for signs of compromise before patching. If there's any delay in patching, check TeamCity logs for anomalous build triggers, unexpected user creation, unusual network connections from the TeamCity server, or new scheduled tasks and cron jobs. Attackers often establish persistence before an organization realizes they're breached.


    Review what your TeamCity server can reach. Map the blast radius: what credentials does it hold? What environments can it deploy to? What secrets are stored in the configuration? Even if you patch cleanly, this audit is overdue.


    Restrict network access at the perimeter. TeamCity should not be exposed directly to the internet. If it is, put it behind a VPN or restrict access by IP. This reduces the attack surface for the next vulnerability in the class.


    Check for lateral secrets. Build servers accumulate credentials over time. Rotate any API keys, cloud credentials, and service account tokens that were accessible to TeamCity — treat them as potentially compromised until proven otherwise.


    ---


    ## HackWire Analysis


    The deeper problem here isn't TeamCity specifically — it's that the security community has known for years that CI/CD infrastructure is high-value, chronically under-protected, and repeatedly targeted, yet enterprise security programs still treat build servers as second-class citizens compared to web-facing applications or endpoint fleets.


    CVE-2026-63077 is the third critical TeamCity exploitation in roughly three years. Each time, the attack pattern is the same: a critical unauthenticated flaw disclosed, patch available same day or within days, exploitation in the wild within a week or two, and then a wave of incidents that trace back to organizations that were slow on the update.


    What's worth watching with this one is how quickly the threat actor ecosystem fragments. The 2024 TeamCity exploits attracted simultaneously: North Korean state actors (software supply chain targeting), ransomware operators (data exfiltration plus encryption), and commodity attackers just looking for initial access to sell. When a flaw is this clean — no auth, RCE, widely deployed platform — it becomes a crowded exploitation market fast.


    The supply chain angle is still the story that deserves more attention. Every software company running a vulnerable TeamCity instance is a potential pivot point into their customers. Downstream impact from a single compromised vendor can be orders of magnitude larger than the breach itself. Security teams at software vendors need to treat this not just as a build server problem but as a customer trust and liability question.


    For defenders: this vulnerability class rewards speed. The organizations that patch within 24–48 hours of disclosure consistently avoid the incident. The ones that wait for the next monthly patching cycle consistently end up in the breach column. The gap between those two outcomes is entirely operational, not technical.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)