TeamCity CVE-2026-63077 Is Being Exploited, Exploit Code Public

On August 5, 2026, the US cybersecurity agency CISA added CVE-2026-63077, a flaw in JetBrains TeamCity, to its catalog of vulnerabilities known to be under active attack. The remediation deadline is August 8 — three days after the listing.

That catalog is the KEV list (Known Exploited Vulnerabilities), and US federal agencies are legally required to fix anything on it within the stated window. Until recently that window was two to three weeks. Three days is close to unprecedented.

The flaw itself has been public since July 27, when JetBrains shipped a fix alongside the disclosure. It requires no username, no password, and no user interaction: anyone who can reach the server over HTTP can run commands on it. Severity is rated 9.8 out of 10.

When this article first went out, CISA had not published the evidence behind its decision. That gap closed within a week. JetBrains itself now says it has "received reports of active exploitation, as well as attempted exploitation" and has published indicators administrators can search for. On August 7, the security firm Rapid7 went further and released a root-cause analysis and working exploit code.

So the situation has moved from "suspected" to "it is happening, and anyone can reproduce it." If you run TeamCity on your own servers, patching is only half the job. You also need to check whether you were breached before you patched. The steps for that are in the second half of this article.

What TeamCity actually does

TeamCity is an automation server that turns source code into shipping products. It takes what developers write, runs the tests, packages the result into an application or installer, and pushes it out to wherever it needs to go. In factory terms, it is the assembly line and the loading dock combined.

The industry calls this CI/CD. TeamCity is one of the better-known products in the category, built by JetBrains, the Czech company behind the IntelliJ IDEA development environment. Earlier this year, another JetBrains product — Hub, which manages staff accounts — carried a flaw rated at the maximum 10.0.

What makes this class of server dangerous is what has to be stored on it. To assemble and ship a product, the machine needs credentials for the distribution servers, the keys used to sign the application, administrative access to cloud accounts, and the source code itself. All of it lives there.

So losing this box does not mean losing one company's data. Everyone who uses the software that company ships is downstream. The 2020 SolarWinds incident, in which attacker code was folded into a legitimate signed update and distributed worldwide, happened because that assembly line was compromised. Build servers remain a standing target as an entry point for attacks on the software supply chain.

Inside CVE-2026-63077

The weak point is the agent polling protocol. A TeamCity deployment normally runs with several worker machines (agents) attached, and those agents periodically call home to ask the main server whether there is work to do. The endpoint that receives those calls was not checking properly.

The technical classification is CWE-502, deserialization of untrusted data: the software takes data arriving from outside and reassembles it into live program objects before checking what it contains. If instructions are hidden inside the data being reassembled, they simply run.

The result is that anyone who can reach the TeamCity web interface can walk past authentication and operate the server. According to the JetBrains advisory, the flaw was reported privately by Antoni Tremblay on July 10 and disclosed 17 days later together with the fix.

Why the hole existed — an allowlist that never cleared the defaults

Rapid7's analysis, published on August 7, pinned the cause down precisely. It comes down to one thing: a safety allowlist was added on top of defaults that should have been cleared first.

TeamCity uses a component called XStream to rebuild the data agents send it. XStream lets you hand it a list saying "only allow these types," so that dangerous ones are never reconstructed. TeamCity added its own protocol types to that list but never revoked the broad permissions XStream already carried. The result was not a tight allowlist but "the defaults, plus a few more."

That looseness matters because Java permissions cover not just the named type but everything derived from it. Permitting Map covers every class that implements Map; permitting Throwable covers every kind of exception. Attackers threaded a chain of objects through that gap. In Rapid7's account they smuggle in a database connection configuration disguised as an exception, pry it open through another component, and end up writing a file containing executable code into the web root — after which a single request runs it.

The fix is almost trivially small: one line that says "deny everything" before the allowlist is applied. That wipes out the broad defaults so only the types TeamCity explicitly names get through. A single line of configuration in the wrong order was all it took to leave the server open to anyone on the internet.

Who goes looking for these servers, and what they take

The groups that hunt for exposed TeamCity installations are ransomware crews and hacking teams working for foreign governments. That is not speculation. Both have already done exactly this to this product, twice.

What they do here, before any encryption or ransom note, is tamper with the products being shipped out. An attacker holding the build server can slip their own code into an update that was assembled through the normal process and carries a valid signature. To whoever receives it, it looks exactly like a legitimate release from the vendor.

The damage lands in two places. Ordinary users install an update they have no reason to distrust, and infect themselves. The company doing the development loses its signing keys and cloud credentials, and has to treat every release it has already shipped as suspect. As with the large ransomware cases that have hit companies in Japan, the way in is usually a single server that was facing the internet.

Why the deadline is three days

The most striking thing here is not the severity score. It is how little time was given.

Historically, anything landing on the KEV list came with a two-week deadline, under a 2021 directive known as BOD 22-01. On June 10, 2026, CISA revoked that directive and replaced it with BOD 26-04. The fixed timeline is gone; deadlines now scale with risk.

Four factors decide the window.

All four together put a vulnerability in the shortest bracket: three days. CVE-2026-63077 ticks every box. Added August 5, due August 8 — the arithmetic works out exactly.

The three-day bracket also asks for more than patching. The implementation guidance requires that within those same three days, agencies also complete forensic triage to determine whether the server has already been broken into. Not "fix it," but "fix it and confirm you were not already too late."

The reason CISA gives in the directive for compressing timelines is that attackers are now using AI, shrinking the gap between a patch going public and exploitation beginning. Since the new scheme took effect, the same three-day bracket has appeared elsewhere: a Langflow vulnerability listed on August 4 carried an August 7 deadline. This is less an emergency than a new baseline taking hold.

It is being exploited — the vendor has confirmed it

On the morning of August 6, the only thing that was clear was that CISA had added the flaw to its catalog. The vendor advisory still said no exploitation was known, no exploit code was circulating, and no victims had come forward. So this article originally stopped at "CISA says it has evidence, but the substance of that evidence is unknown."

That caveat no longer applies. In a follow-up advisory, JetBrains stated plainly that it has "received reports of active exploitation, as well as attempted exploitation, targeting unpatched TeamCity servers." With the vendor confirming it directly, CISA's call is corroborated. The U.S. government's own enrichment data was updated the same day, moving from "no known exploitation" on July 28 to "exploitation active."

Then, on August 7, the security firm Rapid7 published both a root-cause analysis and working exploit code. The research is credited to Stephen Fewer, and the code is freely available on GitHub. Several mirror repositories have followed.

The practical meaning for attackers is simple. Turning this flaw into a weapon used to require real skill; now it requires downloading a file and running it. Any unpatched server that can be found from the outside is finished.

Checking whether you were already breached

Because the attacks were running before disclosure, you have to rule out having been breached before you applied the patch. JetBrains asks administrators to search server logs for three things.

The third is the clearest signal. TeamCity distributes work to attached build agents, and an agent the attacker registered is a foothold that can run commands inside your network. Open the agent list in the admin console and look for names nobody recognizes.

If you find any of these — or if you keep no logs and cannot tell — patching alone is not enough. The rule is to treat every key and credential stored on that server as taken and rotate all of them: deployment credentials, code signing keys, cloud permissions, third-party tokens. Fixing TeamCity does nothing about keys that already walked out the door.

If you cannot patch immediately, JetBrains points to the security patch plugin available for 2017.1 and later and to moving the server off the public internet. It also recommends running TeamCity with minimal operating system privileges and separating the server from its build agents.

TeamCity has been used as a stepping stone twice already

The reason not to shrug this off is the product's history.

In October 2023, an authentication bypass in TeamCity, CVE-2023-42793, was exploited by two hacking groups tied to the North Korean government. Microsoft's analysis documented attackers creating new accounts on compromised machines, adding them to administrator groups, and dumping credentials. That December, CISA, the FBI, the NSA and Polish authorities jointly announced that Russia's Foreign Intelligence Service (SVR) was exploiting the same hole worldwide.

In March 2024, a different bypass, CVE-2024-27198, went public, and this time ransomware operators moved in. Trend Micro traced the Jasmin ransomware through it; GuidePoint Security reported BianLian doing the same. Rogue administrator accounts, cryptocurrency miners and remote access tools were all observed being planted.

How fast that started is on the record. Scanning began the same day the technical details went public.

State actors in 2023, financially motivated crews in 2024. As a target, this product is well known. And the current flaw is easier to reach than either of the previous two: no login of any kind is required.

Working out whether you are affected

Two questions. First, are you running the self-hosted version? If your team uses TeamCity Cloud, run by JetBrains, this does not apply. JetBrains states it has verified that no Cloud environment was compromised through this flaw.

If you host it yourself, the second question is which version.

For environments that cannot take a full version upgrade immediately, JetBrains provides a security patch plugin covering releases from 2017.1 onward. It can be pulled automatically from the TeamCity administration screen or installed by hand. It touches far less than a version upgrade, which makes it the realistic option where there is no time to test one.

This is also a good moment to ask whether the server needs to be reachable from the internet at all. The flaw only works for someone who can reach the TeamCity interface. If it is confined behind a VPN or the corporate network, mass scanning does not find it. JetBrains likewise recommends restricting access to the users and systems that genuinely need it.

And if the server has been publicly reachable at any point, do not stop at updating. This is precisely why BOD 26-04 pairs the patch with forensic triage inside the same three days. Look for administrator accounts nobody created, build configurations with steps nobody added, and signs that stored credentials have been used. In both previous TeamCity intrusions, unauthorized account creation was the first trace left behind.

How many are exposed

There is no reliable count.

The device search service FOFA posted "143.4K+ results" on July 28, the day after disclosure. That is a count of search matches, not of vulnerable servers. For comparison, earlier coverage cited Shodan figures of over 3,000 hosts in 2023 and around 2,200 in 2024. No 2026 equivalent has been published.

No data on installations in Japan surfaced either, and neither JPCERT/CC nor IPA had issued an advisory as of August 12. Japanese-language guidance is still catching up.

Rapid7, the first security vendor to cover the flaw in depth, flagged the stakes two days after disclosure.

How this unfolded

← Swipe to navigate

What the three-day figure is telling us

CVE-2026-63077 itself is a well-defined problem. The fix has been out for nearly two weeks, and there is a patch plugin for older installations. If you run TeamCity on your own servers, you update it. That is the whole task.

The more consequential detail is the US government setting the clock at three days. Patching and then confirming you have not already been breached, all within seventy-two hours, is simply not achievable under the change-management processes most enterprises operate. In practice, a KEV listing has shifted from something you schedule to something that interrupts the schedule.

This case also became a textbook example of the government moving first and the evidence catching up afterwards. On August 5, CISA published no justification and the vendor still said it knew of no exploitation. Two days later the vendor had confirmed exploitation and working exploit code was public. Anyone who waited for the evidence would have been waiting while the exploit went public. Acting the moment something lands in KEV was vindicated by the outcome.

TeamCity was used by a state intelligence service in 2023 and by criminal groups in 2024. In 2026 the third round has begun. The fix has been available since July 27, and applying it closes the hole itself. What is left is confirming you were not breached before you closed it, and treating the keys you stored there as suspect. The danger of a build server is that what gets stolen is not your own data, but the trust of everyone who uses what you ship.

Sources

• ▸ JetBrains Blog - Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077) (July 27, 2026)
• ▸ CISA - Known Exploited Vulnerabilities Catalog (raw feed, catalogVersion 2026.08.05) (August 5, 2026)
• ▸ CISA - BOD 26-04: Prioritizing Security Updates Based on Risk (June 10, 2026)
• ▸ CISA - BOD 26-04 Implementation Guidance (June 10, 2026)
• ▸ NVD - CVE-2026-63077 (July 27, 2026)
• ▸ Rapid7 - CVE-2026-63077: Critical unauthenticated remote code execution in JetBrains TeamCity (July 29, 2026)
• ▸ JetBrains Blog - CVE-2026-63077 Update (active exploitation confirmed, indicators of compromise) (August 2026)
• ▸ Rapid7 - Rapid7 Analysis of CVE-2026-63077 (root cause) (August 7, 2026)
• ▸ GitHub - sfewer-r7/CVE-2026-63077 (published proof-of-concept) (August 7, 2026)
• ▸ Help Net Security - JetBrains fixes critical unauthenticated RCE in TeamCity On-Premises (July 28, 2026)
• ▸ Microsoft Security - Multiple North Korean threat actors exploiting the TeamCity CVE-2023-42793 vulnerability (October 18, 2023)
• ▸ CISA - AA23-347A: Russian Foreign Intelligence Service (SVR) Exploiting JetBrains TeamCity CVE Globally (December 13, 2023)
• ▸ Trend Micro - TeamCity Vulnerability Exploits Lead to Jasmin Ransomware (March 2024)
• ▸ GuidePoint Security - Threat Actors Actively Exploit JetBrains TeamCity Flaws to Deliver Malware (March 2024)