VMware vCenter CVE-2026-59310 Exploited: Patch Now, No Workaround

VMware vCenter, the platform companies use to manage their virtual servers from a single console, contains a flaw that lets an attacker take over the server without ever logging in: CVE-2026-59310, rated 9.8. Real-world intrusions began just five days after the fix shipped. German research firm QUIRSO has tracked 361 victims across 47 countries as of August 7.

On August 18, 2026, the US agency CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog. Federal agencies were given until August 21, 2026 — just three days. And for vulnerabilities in this tier, patching alone is not enough: agencies are also required to check whether they have already been breached.

There is no workaround. No configuration change will hold the line; the only option is to move to the fixed builds Broadcom (the semiconductor and software company that acquired VMware) has released. This article starts with the practical questions: how to tell whether your environment is affected, which version numbers to upgrade to, and how to check whether an intruder is already inside.

Is your environment affected, and what do you upgrade to?

The affected product is self-hosted vCenter Server. Broadcom's security advisory VMSA-2026-0006 (published July 29, 2026, revised August 3) lists the following target builds. A single wrong character means the wrong build, so copy them down exactly.

The same advisory fixes five issues in total. One of them, CVE-2026-59309 (also rated 9.8), lets an attacker walk straight past authentication on an internal service that handles user data — and according to security firm Rapid7's analysis, gain unauthorized access to vCenter's administrative side. Exploitation of that flaw has been observed too, yet it is not in KEV. Prioritizing by CVE number alone is exactly how something like this slips through. The same update closes both, so there is no point worrying about only one of them.

No fixes are available for vSphere 6.5 and 6.7, and Broadcom is pushing customers toward newer generations. There is also a caveat that applying 8.0 U3k temporarily restricts upgrade paths to the next generation — which makes this awkward: the security fix arrives bundled with pressure to migrate products.

Who is behind this, and what do they want?

The activity is being driven by an organized group focused on long-term persistence and data collection. Based on Chinese-language artifacts left in scripts, the tooling in use, the working hours observed (the same time zone as Japan), and the complete absence of victims in mainland China, QUIRSO assesses with moderate confidence that this is likely the work of a Chinese-speaking group. No specific name has been attached to it.

What they do is plant a scheduled task disguised as a legitimate VMware service on the compromised vCenter and settle in. They tamper with the mechanism the server uses to run programs on a schedule, causing it to open connections outward to servers under their control. Because the traffic goes out from the inside rather than coming in from outside, it slips past firewalls built to block inbound intrusion. The configuration survives reboots.

That is where the real work begins. They harvest the credentials stored in vCenter, move laterally to the ESXi hosts underneath (the layer that actually runs the virtual machines), and exfiltrate virtual machine files. In at least one case, files on ESXi were encrypted and their extensions rewritten. Researchers, however, read this not as a ransom play but as a smokescreen: destroying logs to obstruct the investigation.

Here is what the damage looks like in practice. For ordinary users of a service, it shows up one morning as internal systems or a partner's service simply not connecting. For the company running the platform, it means business interruption, data loss on a per-VM basis, destroyed backups, and the investigation cost that comes with not knowing how long the intruders have been inside. Some organizations have had their virtualization platform taken down and found that their financial closing process ground to a halt. This is not a story that ends at a data breach.

What vCenter is, and why it keeps getting targeted

Virtualization is the technology that lets a single physical server host multiple "virtual servers." VMware is the flagship product family in this space: ESXi is the layer that actually runs the virtual servers, and vCenter is the management software that oversees dozens or hundreds of them at once. From the vCenter console, an administrator can start, stop, clone, and migrate servers in bulk.

In other words, vCenter is the keyring where the most privilege in the corporate infrastructure is concentrated. Compromise one box and you hold effective control over hundreds, which makes it an efficient target. The way this campaign spreads cleanly from vCenter to ESXi is exactly what that structure predicts.

This is not the first time. CISA's KEV catalog now lists 33 VMware-related vulnerabilities. CVE-2021-21972 from 2021 stands out in particular: it was the same class of flaw — one that lets you climb back up a directory level — with the same 9.8 rating and the same no-login-required condition. Five years apart, the same type of hole has put vCenter in KEV twice.

In the wake of the licensing changes that followed Broadcom's acquisition, a growing number of Japanese companies are weighing a move to other platforms. Nikkei xTECH has reported cases of price increases as large as 20x, and the Japan Fair Trade Commission published the results of its review on July 3, 2026 (the review was closed without a finding of violation). But migrations take years. "We're switching eventually" is not a reason to leave the vCenter you are running today unprotected. We have also covered a vulnerability in VMware's load balancer and a flaw that leaks vCenter administrator credentials through a migration tool. It is during a migration that the number of holes goes up.

Breaking down how it works

The problem lies in vCenter's built-in log-receiving component (the Syslog server). It takes in and stores activity records sent from devices around the network, which means it keeps a port open to receive external traffic at all times.

That component contained a directory traversal flaw. When assembling the destination filename it failed to reject "go up one level" sequences, allowing files to be written to locations that should be off limits. Being able to choose where you write means being able to replace a configuration file the system reads — which in turn leads to arbitrary code execution. According to QUIRSO's investigation, the code runs with administrator-level (root) privileges.

The reason the severity reaches 9.8 is how few preconditions there are. No account is needed in advance, nobody has to click a link, and simply being in a position to reach vCenter over the network is enough. That covers attackers who have already gained a foothold on the internal network, and — for environments that expose the management console to the internet — attackers reaching it directly from outside.

The attack chain runs like this: send crafted traffic to the logging component, execute code as administrator, plant a scheduled task disguised as a legitimate service, use the public tool reverse_ssh to open a connection to an external command server, then steal credentials and spread to ESXi. What stands out is how little custom tooling is involved — the operators mostly get by with commands already present on the server, which is precisely what makes them hard to spot.

Five days from disclosure to intrusion — and how it spread from there

What makes this case especially serious is the gap between the fix shipping and the attacks starting. Laying out QUIRSO's observations as reported by BleepingComputer alongside Shadowserver's special report gives the following timeline.

The 361 confirmed victim IP addresses are spread across 47 countries, with five countries accounting for the majority: Germany 55, the United States 41, Turkey 38, Iran 26, and France 25. No figure has been published for Japan. QUIRSO also notes that the number of IPs does not equal the number of affected organizations, since a single IP on shared hosting may serve multiple customers. These numbers represent what one firm observed in the course of its investigation, not a global total.

It is worth noting that in its July 29 write-up, Rapid7 stated it had seen no signs of exploitation or scanning. Quiet at disclosure did not mean safe. The work of reconstructing an attack technique from the patch diff had already been completed before any proof-of-concept code appeared in public.

One more thing does not sit right. Broadcom itself still has not changed its line that there is no information indicating exploitation. CISA, Shadowserver, QUIRSO, and Japan's JPCERT/CC have all reported compromises, yet the vendor's own guidance remains at a different temperature. Judging by the vendor's wording alone will slow your response down.

A three-day deadline means "patch and investigate," not just "patch"

Vulnerabilities added to KEV come with a remediation deadline for US federal agencies. The three-day window here stems from BOD 26-04, the directive under which CISA changed how it operates. Is it exposed to the internet? Is it being actively exploited? Can exploitation be automated? Does it hand over the entire system? Priority is set by those four conditions, and anything that ticks all of them lands in the shortest tier.

The important part is that this tier requires not just applying the fix but also investigating whether a compromise has already occurred. Private companies in Japan are under no legal obligation here, but the underlying judgment — issued by the US government — carries the same meaning: assume you may already be inside the blast radius and verify. Since the attacks began on August 3, even organizations that updated in early August may have been breached before they patched.

Checking whether you have already been breached

Applying the patch does not remove scheduled tasks that have already been planted. Alongside the update, work through the following.

First, outbound traffic from vCenter. This campaign opens SSH connections (the protocol used for remote server administration) from the inside out. Check firewall and proxy records back to July 29 for vCenter making sustained connections to IP addresses you do not manage. A management server chatting continuously with the outside world on its own initiative is not a normal state.

Second, scheduled task configurations. Look for jobs you do not recognize, and for anything registered from late July onward. These attackers blend in by giving their tasks names that resemble legitimate VMware services, so a plausible-looking name is no evidence of safety. Filtering by timestamp is the reliable approach.

Third, the logging component and the state of your ESXi hosts. Are there files in places you never expected? Are ESXi logs unnaturally missing chunks? Have unfamiliar administrator accounts appeared? Attackers pull credentials from vCenter and spread to ESXi, so you cannot stop at vCenter.

QUIRSO has published detection rules on GitHub for finding reverse_ssh. Bear in mind, though, that reverse_ssh is a legitimate tool also used in security assessments, so do not treat a hit as conclusive on its own — look for the combination of "sitting on top of vCenter" and "accompanied by unexpected outbound traffic." If you are unsure how to read the results, the fastest route is to consult your security team or the incident response firm you have on contract, citing the CVE number and the July 29 date.

Japan's public agencies have yet to issue a standalone alert

Severity 9.8, exploitation confirmed, no workaround. Even so, as of August 19, 2026, there is no dedicated page for this issue in JPCERT/CC's alerts, in JVN, or in IPA's important security notices. JPCERT/CC did report in its August 19 Weekly Report that "since August 3, vCenter instances have been compromised by attacks believed to exploit CVE-2026-59310, with backdoors and other implants installed" — but it sits as one item inside a weekly roundup.

Japanese-language coverage does exist. Security NEXT covered the vulnerability itself on July 29 and its KEV listing on August 19, while @IT and ITmedia Enterprise both picked it up in early August. Still, when it comes to deciding "are we affected, and what do we have to do by when," no clear directive has come from a public agency yet. So if "JPCERT hasn't published anything" threatens to stall your internal response, use the contents of this article as your justification.

Three other flaws confirmed as exploited on the same day

On August 18, 2026, CISA added four vulnerabilities to KEV at once, vCenter among them. All four share the August 21 deadline. The other three are products in everyday use in Japanese workplaces, so they are worth a mention. You can search the full catalog from our CISA KEV dashboard.

CVE-2026-55040 affects SharePoint Server, Microsoft's product for internal portals and document sharing. Several validation checks on the electronic tokens that prove a user's identity were missing, so a forged token could be used to impersonate an administrator. The fix is included in the July 2026 monthly update. The day after Rapid7 published proof-of-concept code on August 11, real attacks were observed. If you run SharePoint on premises, review your patch status alongside our roundup of the SharePoint vulnerabilities that came in quick succession in July.

CVE-2026-33824 in Windows is a bug in the component responsible for VPN key exchange. The fix shipped in the April 2026 monthly update, covering a broad range of Windows 10, Windows 11, and Windows Server builds. Unit 42, Palo Alto Networks' research arm, reports that the flaw was used in a campaign in which AI assembled the attack steps automatically. If you have a backlog of monthly updates, start clearing it here.

CVE-2026-65400 in macOS allows a connection to a Mac's Screen Sharing without the correct password. Anyone on the same network can read and write files with administrator privileges. The fixes are in macOS Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9, which Apple released on August 6. A Dutch government agency has warned that it confirmed attacks abusing this hole to gain administrator privileges and install cryptocurrency mining software. If you do not use Screen Sharing, the safe move is to turn the feature off entirely.

What to do right now

There are three things.

First, update. U3k or U2f for the 8.0 line, 9.0.2.0100 for the 9.0 line, 9.1.0.0300 for the 9.1 line. With no workaround available, build your schedule on the assumption that the hole stays wide open the entire time you are validating in a test environment. The US government gave federal agencies just three days from the KEV listing.

Second, narrow the reachable surface. Check right now whether your vCenter management console is directly visible from the internet. The management plane belongs on a network separated from the business network, reachable only from a limited set of endpoints. That design still matters after the update is done.

Third, confirm whether you have already been breached. Take the three items from the previous section — outbound traffic, scheduled task configurations, and the state of your ESXi hosts — and review them back to July 29. Stop at the update and any persistence mechanism already planted will survive. The short deadline in this case exists precisely to force that extra step.

When a virtualization platform goes down, the impact reaches the entire business. Just like WebLogic, a product that has been targeted relentlessly for years, once vCenter lands on the list it will be probed continuously. The practical move is to treat this update as the occasion to revisit how exposed your management servers are.

Summary

CVE-2026-59310 in VMware vCenter is a 9.8-severity flaw that lets an attacker take over the server without logging in, and real intrusions began five days after the fix was published. By August 7, victims had been confirmed in 47 countries across 361 cases; on August 18, CISA designated it as actively exploited and set an August 21 deadline.

There is no workaround. Updating to 8.0 U3k (or U2f), 9.0.2.0100, or 9.1.0.0300 is the only remedy. And to rule out a breach that predates your update, review outbound traffic and scheduled task configurations going back to July 29. The worst possible landing is calling it done with "we applied the patch" while someone else still holds the keys to your entire estate.

References

• ▸NVD - CVE-2026-59310 (severity 9.8, published July 30, 2026)
• ▸NVD - CVE-2026-59309
• ▸Broadcom - VMSA-2026-0006.1 (published July 29, 2026 / revised August 3)
• ▸VMware - VMSA-2026-0006 supplemental FAQ (GitHub)
• ▸CISA - Known Exploited Vulnerabilities Catalog (August 18, 2026 edition, deadline August 21, 2026)
• ▸CISA - BOD 26-04 Prioritizing Security Updates Based on Risk
• ▸Shadowserver - VMware vCenter CVE-2026-59310 Exploitation Victim Special Report (August 13, 2026)
• ▸Rapid7 - Critical VMware vCenter Vulnerabilities Allow Authentication Bypass and Remote Code Execution (July 29, 2026)
• ▸BleepingComputer - Critical VMware vCenter RCE flaw exploited for reverse SSH access (August 13, 2026)
• ▸The Hacker News - Suspected China-Nexus Actor Exploits VMware vCenter Flaw (August 2026)
• ▸SecurityWeek - Critical VMware vCenter Vulnerability in Attackers' Crosshairs
• ▸Infosecurity Magazine - vCenter Flaw Exploited Just Five Days After Disclosure
• ▸JPCERT/CC - Weekly Report 2026-08-19 [3] Vulnerabilities in multiple VMware products
• ▸Security NEXT - vCenter vulnerability added to KEV following confirmed exploitation (August 19, 2026)
• ▸Rapid7 - Microsoft SharePoint JWT Token Authentication Bypass (CVE-2026-55040)
• ▸Unit 42 - Analysis of an autonomous AI cyber attack campaign (July 30, 2026)
• ▸Apple - About the security content of macOS Tahoe 26.6.1