Top/Articles/CISA Gives Three Days to Patch TeamCity Flaw CVE-2026-63077
teamcity-cve-cover-en

CISA Gives Three Days to Patch TeamCity Flaw CVE-2026-63077

CISA gave US agencies three days to patch a TeamCity flaw that lets anyone take over the build server with no login. Self-hosted only; fixed since July 27.

NewsPublished Aug. 6, 2026 Updated today
Table of contents
Key takeaways

CISA gave US agencies three days to patch a TeamCity flaw that lets anyone take over the build server with no login. Self-hosted only; fixed since July 27.

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.

One thing needs stating plainly up front. As of the morning of August 6, CISA has not published the evidence behind its decision. JetBrains' own advisory still says the company is not aware of any exploitation, and has not been updated. That contradiction is examined in detail below.

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

ItemDetail
IdentifierCVE-2026-63077
AffectedTeamCity On-Premises,
all versions
Not affectedTeamCity Cloud
(JetBrains-hosted)
Severity9.8 / 10 (critical)
Login requiredNo
User interactionNone needed
ImpactArbitrary command execution
on the server
DisclosedJuly 27, 2026
Added to KEVAugust 5, 2026
Federal deadlineAugust 8, 2026

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.

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.

FactorMeaningThis case
Internet exposureReachable from
outside
Yes
Known exploitationListed in KEVYes (August 5)
AutomatableCan be fired at
targets in bulk
Yes
Technical impactPartial or total
control
Total

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.

Is it actually being exploited?

This is the part that needs the most care.

By definition, KEV lists only vulnerabilities with confirmed exploitation. So as of August 5, CISA holds evidence of attacks. Reading the raw catalog data CISA publishes directly confirms the entry: added 2026-08-05, due 2026-08-08, ransomware use recorded as "Unknown." That much is solid.

The problem is that nothing beyond it exists.

✓ Confirmed (as of the morning of August 6, 2026)

  • CISA added CVE-2026-63077 to KEV on August 5 with an August 8 deadline (verified against the catalog itself)
  • It was the only entry added that day
  • The JetBrains advisory remains as published on July 27, stating that as of publication the company is not aware of any active exploitation

? Not established

  • ?Who observed what attack, and when — CISA has published no basis
  • ?Exploit code in circulation — no public proof-of-concept was found
  • ?Victims — no organization has disclosed a breach tied to this flaw
  • ?Japanese advisories — nothing from JPCERT/CC, IPA or JVN

Stranger still, CISA's own enrichment data for this CVE still records exploitation status as "none," unchanged since July 28. The team that listed it in KEV and the team that maintains the assessment data are out of step.

One reading is simply timing: the KEV update landed in the early hours of August 6 Japan time, before any vendor analysis or press coverage could follow. The world may just not have caught up yet.

But there is precedent for KEV listings that do not mean "attacks started today." CVE-2024-27199, another TeamCity flaw, was added to KEV on April 20, 2026 — roughly two years after exploitation was confirmed. Listing dates and attack timelines do not necessarily line up.

The honest summary is that CISA has stated it obtained evidence of exploitation, and has not shown what that evidence is. Neither "attacks are widespread" nor "this is still safe" can be asserted. For the purposes of deciding what to do, though, it hardly matters — the fix has been available for over a week.

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.

What you runAffectedAction
2026.1.2 or earlierYesUpdate to 2026.1.3
2025.11.6 or earlierYesUpdate to 2025.11.7
Older releases
from 2017.1 on
YesApply the security
patch plugin
TeamCity CloudNoNothing to do

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 the morning of August 6. 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.

And an uncomfortable gap remains. CISA says it confirmed exploitation but has not shown what it saw. JetBrains still says it knows of none. The government's judgment has arrived ahead of its justification, and defenders are being asked to act without waiting for the rest.

TeamCity was used by a state intelligence service in 2023 and by criminal groups in 2024. Whether there is a third round is unknown. What is known is that the fix exists and the deadline is August 8.

Sources

avatar-m-1

Makoto Horikawa

Backend Engineer / AWS / Django