CVE-2026-63077: CISA Flags TeamCity RCE in Ransomware Attacks

CISA's KEV update adds ransomware use to CVE-2026-63077​

The news came from BleepingComputer, which reported that CISA warned federal agencies on Wednesday that ransomware gangs are now also exploiting a critical JetBrains TeamCity vulnerability patched in July. The KEV catalog has a field that marks whether a vulnerability is known to be used in ransomware campaigns. That field is what changed. CISA has published no detail beyond it. BleepingComputer says CISA has not yet shared information about attacks targeting CVE-2026-63077. As a result, no ransomware group, victim, or set of attacker techniques has been publicly tied to this CVE.

Other coverage of the ransomware designation so far appears to follow BleepingComputer's report, and the CISA catalog entry itself was not available to check directly. Treat the designation as CISA's finding, reported by BleepingComputer. The fact that the flaw is being exploited at all is well corroborated: CISA's August listing, JetBrains' own follow-up advisory, and several security firms all confirm it.

BleepingComputer also puts the flag in historical context. It reports that since October 2023, the cybersecurity agency has tagged four TeamCity security issues as exploited in the wild, all of which have also been abused in ransomware attacks. That is BleepingComputer's count of CISA's catalog, not an independent tally. The pattern still tells TeamCity administrators something: every TeamCity bug that has reached KEV has later been used by ransomware operators.

How the TeamCity agent polling flaw turns HTTP access into command execution​

JetBrains' advisory describes the bug in plain terms. An unauthenticated attacker who can reach a TeamCity server over HTTP(S) can go through the agent polling protocol (the channel build agents use to check in with the server for work), get past authentication checks, and run arbitrary operating-system commands with the privileges of the TeamCity server process. JetBrains says the flaw affects every TeamCity On-Premises version. TeamCity Cloud customers don't need to do anything because JetBrains has already applied mitigations there, and it says it found no evidence that Cloud environments were exploited.

Independent analysis fills in the bug class. Rapid7 says the issue is classified as deserialization of untrusted data and has a CVSS score of 9.8. CISA's own KEV description, as quoted by The Hacker News, says "JetBrains TeamCity contains a deserialization of untrusted data vulnerability that could allow unauthenticated remote code execution via the agent polling protocol". Rapid7 published a root-cause analysis on August 7 and found that a vulnerable TeamCity server creates a permissive XStream allowlist. XStream is the Java library whose exception names show up in the log indicators JetBrains later published.

The real damage depends on how the server is set up. The attacker's commands run as the TeamCity server process, not automatically as root or SYSTEM, so a server running with minimal OS rights limits what an intruder can do directly. JetBrains' list of what it can still expose is serious: TeamCity data, configurations and stored credentials, changes to server state, and possible compromise of build artifacts and downstream CI/CD pipelines. That last item turns a server compromise into a supply-chain risk. If attackers can tamper with what the build server produces, the software you ship to others becomes a possible carrier.

From July patch to September ransomware flag: the CVE-2026-63077 timeline​

The dates show how quickly the window closed. They also include one small discrepancy that is worth noting.

When JetBrains disclosed the bug, it said it knew of no active exploitation. That changed within about nine days. According to The Hacker News, under Binding Operational Directive (BOD) 26-04, Federal Civilian Executive Branch (FCEB) agencies are required to prioritize patching high-risk vulnerabilities listed in the Known Exploited Vulnerabilities (KEV) catalog, and the deadline by which federal agencies must apply software patches or mitigations for CVE-2026-63077 is August 8, 2026. SecurityWeek confirmed the three-day window and noted at the time that there does not appear to be any public information on the attacks exploiting the vulnerability. Seven weeks later, that is still true of the ransomware activity.

JetBrains' August 7 follow-up said that before the exploitation reports came in, it had already built mitigations and made fixes available to all supported customers. In other words, patches existed well before the attacks started.

JetBrains' own Cadence breach shows what a missed TeamCity patch costs​

The clearest public example of CVE-2026-63077's impact comes from JetBrains. Cadence is a JetBrains-hosted service that works with PyCharm through an optional plugin and runs projects on cloud compute. It uses TeamCity to orchestrate that work. JetBrains confirmed that the Cadence server was vulnerable to CVE-2026-63077 and was exploited between August 8 and August 24. JetBrains found the intrusion on August 23 and took the server offline the next day. It said plainly that the server should have been patched as part of its own response, that it was not, and apologized.

JetBrains lists what the attackers reached. They extracted personal data including usernames, real names, email addresses, last-login timestamps and IP addresses. They got a full 2024 backup of the Cadence server. They compromised multiple AWS IAM users and credentials, including accounts belonging to JetBrains employees, and accessed files in S3 buckets in JetBrains' AWS accounts. JetBrains' final update on September 3 said the attackers had access that could have reached storage holding current users' email addresses, project source code and credentials. It is treating that data as potentially exposed.

JetBrains has not described the Cadence incident as ransomware, and nothing public connects it to CISA's September designation. Keep the two stories separate. What Cadence does show is the chain of consequences JetBrains' advisory warned about: an internet-reachable TeamCity server leads to stored secrets, then to cloud accounts, then to source code. JetBrains told Cadence users to revoke and rotate every credential used in executions. That covers cloud keys for AWS, Azure and Google Cloud; tokens for GitHub, GitLab and Bitbucket; credentials for npm, Maven, NuGet and PyPI; container registry logins; and signing keys. Users should also treat all execution inputs and outputs as untrusted.

The IP addresses JetBrains published for observed exploitation of Cadence were 150.109.230.104, 43.153.227.206, 62.210.127.48, 210.247.242.190, 15.235.225.205 and 152.233.30.18. JetBrains says the list is not exhaustive. Seeing none of these addresses does not mean you were unaffected. Seeing one in your own TeamCity access logs is a strong reason to investigate.

Shadowserver's count is falling, but 160 exposed TeamCity servers remain​

The good news is that exposure has dropped. BleepingComputer reports that Shadowserver is now tracking just over 160 TeamCity servers unpatched against the CVE-2026-63077 flaw, down from an initial 700 Internet-exposed servers vulnerable to attacks spotted right after the vulnerability was patched. Most administrators whose TeamCity instances face the internet have acted.

These figures come from internet scanning, so they have limits. They count servers visible from the public internet. They miss servers reachable only from partner networks, VPN users or compromised internal hosts. They also cannot always tell whether a given instance has JetBrains' security patch plugin installed. Ransomware operators often get into internal networks by other routes, so a TeamCity server behind the firewall is not safe just because it doesn't appear in a scan.

A server patched in September also isn't cleared by the patch. It may have been exposed during the seven weeks when exploitation was confirmed. The patch closes the door but does nothing about anyone who already got in. That makes the indicator review described below mandatory for any server that was unpatched and reachable after late July.

TeamCity also has a history with state-sponsored attackers. BleepingComputer notes that because state-backed hacking groups and ransomware gangs have often leveraged TeamCity vulnerabilities in attacks, IT administrators are advised to patch Internet-exposed servers immediately, and cites a U.S.–U.K. warning from October 2024 about Russia's APT29 targeting TeamCity and Zimbra servers "at a mass scale." The Cloud Security Alliance points further back: in December 2023, CISA, the FBI, the NSA, and allied agencies in Poland and the United Kingdom issued a joint advisory attributing large-scale exploitation of an earlier critical TeamCity authentication-bypass flaw, CVE-2023-42793, to Russia's Foreign Intelligence Service. Those campaigns are not linked to CVE-2026-63077. They do explain why attackers keep coming back to TeamCity servers.

Patching TeamCity On-Premises: upgrade, apply the patch plugin, or take it offline​

JetBrains offers two fixes and one stopgap. They apply only to TeamCity On-Premises. TeamCity Cloud tenants have no patching to do.

Option 1: Upgrade to a fixed release​

1. Upgrade the server to TeamCity 2025.11.7 or 2026.1.3, the versions JetBrains names as containing the fix, using the installer or TeamCity's built-in automatic update. Newer releases, including TeamCity 2026.2, have shipped since then. Where you can, move to a current supported release rather than stopping at the July builds.
2. Confirm the server reports the new version after the upgrade and that build agents reconnect.

Option 2: Install the security patch plugin​

If you can't upgrade right away, JetBrains provides a security patch plugin for TeamCity 2017.1 and later.

1. On TeamCity 2024.03 and newer, the server downloads available security patch plugins automatically and notifies administrators if notifications are set up. Go to Administration | Updates and look under Available security updates to review and apply pending patches.
2. On older versions, download and install the plugin manually.
3. On TeamCity 2017.1 through 2018.1, restart the server after installing the plugin. From 2018.2 on, you can enable the plugin without a restart.

The plugin fixes CVE-2026-63077 only. It does not include any other security fixes in newer releases, so treat it as a bridge to an upgrade.

Stopgap: Cut off external access​

JetBrains says a publicly accessible server that can't be patched right away should have external access temporarily restricted. For the longer term, it recommends limiting TeamCity to trusted networks, putting internet-facing servers behind a VPN or another access-control layer, running the server with the minimum OS privileges it needs, and hosting it separately from build agents. JetBrains points out that even an exposed login screen or REST API gives attackers an entry point when the next vulnerability is disclosed.

Hunting for signs of exploitation​

JetBrains' August 7 guidance gives administrators three things to check:

• Search the TeamCity server logs for com.thoughtworks.xstream.converters.ConversionException. JetBrains says the message alone doesn't confirm exploitation, but it can indicate an attempted or successful exploit and should be investigated.
• On a server that is already patched or upgraded, com.thoughtworks.xstream.security.ForbiddenClassException means someone tried to exploit the flaw after patching and the fix blocked it.
• Check the unauthorized build agents list for unexpected entries, especially names starting with scan. JetBrains says these can be removed safely. The date shown for such an agent doesn't necessarily show when the attempt happened, so use the log timestamps when building a timeline.

If you find a ConversionException from before your patch date, treat the server as possibly compromised, not just probed. Based on JetBrains' own Cadence response, that means rotating every credential the server stored or passed to builds, reviewing connected cloud accounts and repositories for unauthorized changes, and checking whether any published artifact could have been tampered with.

What this means for TeamCity administrators​

If you run TeamCity On-Premises, confirm today that every instance is on a fixed release or has the patch plugin. Then look for signs of exploitation before you declare the server clean. TeamCity Cloud customers have nothing to patch. Organizations that patched in late July and never exposed the server outside trusted networks are in the best position, though a log review costs little and is still worth doing.

• CISA's September 23 KEV update marks CVE-2026-63077 as used in ransomware campaigns. No specific attacks, groups or victims have been published.
• TeamCity On-Premises 2025.11.7 and 2026.1.3 fix the flaw. A current supported release is better, and the 2017.1+ patch plugin is a temporary measure that covers only this CVE.
• Servers that were reachable and unpatched after late July should be checked for ConversionException log entries and unexpected agents whose names start with scan.
• A confirmed or likely compromise means rotating stored credentials and build secrets and reviewing downstream artifacts. Patching alone is not enough.
• Internet-facing TeamCity servers belong behind a VPN or access-control layer, running with least-privilege OS accounts on hosts separate from build agents.
• Shadowserver's count of just over 160 unpatched internet-exposed servers covers only what scanners can see. Internal-only instances need the same attention.

CVE-2026-63077 went from private report to confirmed exploitation to ransomware designation in about ten weeks, and JetBrains' own Cadence service was breached through it. If you haven't patched TeamCity, assume attackers have already found your server. If you patched late, what matters now is your logs and your credential inventory. CISA may yet publish details about the ransomware activity behind this designation, but don't wait for that before rotating secrets on a server that was left exposed.