The Cybersecurity and Infrastructure Security Agency confirmed on September 15, 2026, that ransomware gangs have joined attackers already exploiting a critical remote code execution flaw in VMware vCenter Server, according to a BleepingComputer report by Sergiu Gatlan. The bug, tracked as CVE-2026-59310, carries a CVSS score of 9.8 out of 10 and sits in the vCenter Syslog server, where an unauthenticated attacker with network access can run arbitrary code. Broadcom, which owns VMware, shipped a fix on July 29. CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 18 and gave federal agencies just three days to patch.
That compressed timeline, and the jump from opportunistic scanning to ransomware deployment, is why security teams outside government are paying attention today. vCenter sits at the center of most enterprise virtualization stacks, meaning a single unpatched instance can hand an attacker a path into hundreds of virtual machines at once.
What CISA Just Confirmed About CVE-2026-59310
CISA’s KEV catalog entry marks CVE-2026-59310 as a confirmed case of active exploitation tied to ransomware operations, not just proof-of-concept scanning. That distinction matters. CISA typically reserves rapid-turnaround remediation deadlines, in this case three days, for vulnerabilities where it has direct evidence of in-the-wild abuse rather than theoretical risk. Federal civilian agencies running affected vCenter builds had until August 21 to patch or disconnect exposed instances.
Broadcom’s own advisory, hosted on its support portal, lists CVE-2026-59310 alongside a companion flaw, CVE-2026-59309, both affecting VMware Cloud Foundation and vSphere Foundation builds running vCenter 9.0.x.x. Pairing two bugs in a single advisory is common practice at Broadcom when both touch the same subsystem, in this case the Syslog service that vCenter uses to centralize log collection across a virtual environment.
Inside the VMware vCenter Syslog Flaw
CVE-2026-59310 is a directory traversal vulnerability, the kind of bug that lets an attacker manipulate file paths to escape a restricted directory and reach parts of a filesystem that should be off limits. In vCenter’s case, the flaw lives in the syslog server component, a piece of the platform that ordinarily just receives and stores log data from connected hosts.
Directory Traversal, in Plain Terms
A well-behaved syslog server writes incoming log entries to a fixed, sandboxed location. A directory traversal bug breaks that containment: an attacker crafts input that tricks the server into writing, or in this case executing, content outside the intended folder. Because the vCenter Syslog service runs with elevated privileges by design, an attacker who can reach it over the network does not need a password. That is what pushes the CVSS score to 9.8, one tick below the maximum possible severity rating.
No authentication requirement plus network-only access plus code execution is the exact combination that turns a bug into a ransomware delivery mechanism. It removes the two biggest obstacles attackers usually face: stealing credentials and getting a user to click something.
How Ransomware Gangs Are Exploiting the Bug
Once inside vCenter, an attacker effectively controls the management plane for every ESXi host and virtual machine the server administers. That is the appeal for ransomware crews targeting virtualization infrastructure specifically: encrypting a handful of VMX files and datastores can take down dozens of production servers in one pass, which is far more efficient than chasing individual endpoints one at a time.
BleepingComputer’s separate reporting from its VMware coverage desk notes that a related campaign has used access gained through vCenter flaws to plant reverse SSH tools, giving attackers a persistent, low-noise foothold that survives a reboot and blends into normal administrative traffic. Separately, a research note from the Cloud Security Alliance’s research arm describes exploitation of CVE-2026-59310 by what it calls a suspected advanced persistent threat actor seeking unauthenticated remote code execution, a pattern that frequently precedes ransomware deployment once initial access is established and sold or handed off internally.
Timeline: From Patch to Active Exploitation
The gap between disclosure and exploitation keeps shrinking industry-wide, and this case fits the pattern. Broadcom issued fixed builds on July 29. The Hacker News covered the original disclosure of three critical VMware flaws, including this one, in a July 30 report. CISA moved to add CVE-2026-59310 to the KEV catalog by August 18, about three weeks after the patch shipped. By September 15, ransomware gangs were confirmed in the mix.
| Date | Event | Source |
|---|---|---|
| July 29, 2026 | Broadcom ships fixed vCenter builds | Broadcom Security Advisory |
| July 30, 2026 | Public disclosure of three critical VMware flaws | The Hacker News |
| August 18, 2026 | CISA adds CVE-2026-59310 to KEV catalog | CISA KEV |
| August 21, 2026 | Federal remediation deadline | CISA KEV |
| September 15, 2026 | CISA confirms ransomware gangs exploiting the flaw | BleepingComputer |
Why the KEV Catalog Listing Matters
CISA’s KEV catalog exists to cut through the noise of thousands of annual CVEs and flag the small subset attackers are actually using right now. A listing carries legal weight for federal civilian executive branch agencies, which face binding operational directive deadlines to patch. It carries reputational and insurance weight everywhere else, since many cyber insurance policies and vendor risk questionnaires now ask directly whether an organization has unpatched KEV-listed software.
For a platform as widely deployed as vCenter, a KEV listing tends to trigger a second wave of scanning within days, as both defenders and opportunistic attackers treat the catalog as a public target list. Enterprises that had not prioritized the July patch because it lacked confirmed in-the-wild exploitation now have far less room to wait.
Who’s at Risk: vCenter Versions and Deployment Scope
vCenter Server underpins virtualization management for organizations ranging from mid-size data centers to the largest cloud and managed hosting providers. It rarely sits exposed directly to the open internet by design, but misconfigured firewall rules, flat internal networks, and VPN-adjacent management segments routinely put it within reach of an attacker who has already landed a foothold elsewhere in the network.
Affected vs. Fixed Versions
Broadcom’s advisory lists specific fixed builds depending on the vCenter release line an organization runs. Admins on extended-support contracts for older 7.0 branches need to contact Broadcom directly, since that line falls outside the standard patch cadence.
| vCenter Version Line | Status | Fixed Build |
|---|---|---|
| 9.1.x.x | Affected | 9.1.0.0300 |
| 9.0.x.x (incl. Cloud Foundation / vSphere Foundation) | Affected | 9.0.2.0100 |
| 8.0 (U-series) | Affected | 8.0 U3k or 8.0 U2f |
| 7.0 | Affected, extended support only | Contact Broadcom support |
VMware’s Patch and Mitigation Guidance
Broadcom’s guidance is straightforward: update to the fixed build for your version line as soon as possible, since the advisory lists no workaround for CVE-2026-59310. That absence of a workaround is significant. When a vendor cannot offer a configuration change or mitigation as a stopgap, patching becomes the only real option, which raises the stakes for organizations that test changes to management infrastructure slowly.
In the meantime, security teams that cannot patch immediately should restrict network access to the vCenter management interface to the smallest possible set of administrative hosts, and treat any vCenter server reachable from a general-purpose VLAN as an emergency, not a backlog item.
How This Compares to Past Critical vCenter and ESXi Bugs
VMware’s virtualization stack has a track record of high-severity bugs that draw ransomware interest, largely because compromising one management server yields access to everything it controls. CVE-2026-59310 joins a list that includes CVE-2024-37079, a critical vCenter Server DCERPC out-of-bounds write RCE, and a pair of 2025 ESXi flaws, CVE-2025-22225 and CVE-2025-22226, the first an arbitrary kernel write in the VMX process enabling a sandbox escape and the second an ESXi information disclosure bug later tied to ransomware activity. Further back, CVE-2021-22005 gave attackers an arbitrary file upload path into vCenter Server that also saw active exploitation.
| CVE | Product | Flaw Type | Ransomware-Linked |
|---|---|---|---|
| CVE-2026-59310 | vCenter Server (Syslog) | Directory traversal RCE | Yes (confirmed Sept. 2026) |
| CVE-2025-22225 | ESXi (VMX process) | Arbitrary kernel write, sandbox escape | Reported in related coverage |
| CVE-2025-22226 | ESXi | Information disclosure | Reported in related coverage |
| CVE-2024-37079 | vCenter Server (DCERPC) | Out-of-bounds write RCE | No confirmed ransomware link |
| CVE-2021-22005 | vCenter Server | Arbitrary file upload RCE | Yes, exploited in the wild |
The pattern across five years of these disclosures is consistent: unauthenticated or lightly authenticated remote code execution in a component that manages many other systems at once, followed by rapid weaponization once proof-of-concept details circulate.
The Ransomware Groups Circling Virtualization Infrastructure
Ransomware operators have shifted deliberate focus toward hypervisors and management consoles over the past several years, since encrypting a datastore that backs dozens of virtual machines produces far more leverage than encrypting individual Windows endpoints one at a time. CISA’s KEV listing does not name a specific ransomware group tied to CVE-2026-59310 exploitation, and this article will not speculate about attribution beyond what CISA and BleepingComputer have confirmed. What is established is the mechanism: gain code execution on vCenter, pivot to connected ESXi hosts, then encrypt or destroy virtual machine files at scale.
That mechanism is precisely why VMware-adjacent CVEs consistently outperform other bug classes on the ransomware economics dashboard. One successful exploitation event can yield dozens of encrypted machines, multiplying the extortion leverage per attack far beyond what a single compromised laptop or file server would produce.
Market and Enterprise Impact
Enterprises running vCenter now face an unplanned patch cycle on infrastructure that, by its nature, is treated conservatively. Change control for hypervisor management software often runs on quarterly or even annual cycles precisely because an outage or misconfiguration during patching can be as disruptive as an attack. A KEV listing with a confirmed ransomware link collapses that timeline to days, which forces IT operations teams to weigh downtime risk from patching against breach risk from waiting.
Broadcom’s Patch Cadence Under Scrutiny
Since acquiring VMware, Broadcom has faced ongoing criticism over licensing changes and support restructuring, and a critical, no-workaround vulnerability reaching ransomware-confirmed status less than two months after patch release adds pressure on that relationship. Customers on the affected 7.0 branch who must contact support individually for a fix, rather than downloading a public patch, face additional friction at exactly the moment speed matters most.
Detection: What Security Teams Should Check Right Now
Incident responders investigating potential compromise should start by confirming their current build number against the fixed versions Broadcom published, then review vCenter and syslog service logs for anomalous process creation or unexpected outbound connections, a common indicator of a reverse SSH tool being staged for persistence.
# Check the installed vCenter build number
vpxd -v
# Compare against Broadcom's fixed builds:
# 9.1.x.x -> 9.1.0.0300
# 9.0.x.x -> 9.0.2.0100
# 8.0 -> 8.0 U3k or 8.0 U2f
# Review syslog service logs for unexpected write paths or process spawns
grep -Ei "\.\./|/etc/|/bin/sh|reverse" /var/log/vmware/vpxd-syslog/*.logAny hit on that last pattern warrants immediate escalation, isolation of the vCenter host from general network segments, and a credential rotation for every account with administrative access to the affected vCenter instance, since an attacker with code execution can typically harvest stored credentials from the platform’s internal database.
Federal Deadlines vs. Enterprise Reality
CISA’s three-day remediation window applies only to federal civilian executive branch agencies, but the pattern behind that deadline, an aggressive turnaround set specifically because exploitation is confirmed rather than theoretical, reflects how CISA is now handling every KEV entry with a ransomware link. Private enterprises are not bound by the same directive, yet security teams increasingly treat KEV deadlines as an informal industry benchmark for how fast a patch should move once the government signals active abuse.
The mismatch between that expectation and the reality of hypervisor change control, where a botched patch can take down production workloads company-wide, is the core operational tension this disclosure exposes. Most enterprises will not hit a three-day window for vCenter, and CISA’s own guidance implicitly acknowledges that by directing only federal agencies rather than the private sector to that specific deadline.
Historical Context: Virtualization as Ransomware’s Favorite Target
The pivot toward hypervisor-layer attacks did not start this year. ESXi ransomware variants have circulated since at least 2021, and the arbitrary file upload flaw tracked as CVE-2021-22005 was exploited in the wild within weeks of disclosure that same year. What has changed by 2026 is the sophistication of the initial access step: attackers no longer need stolen credentials or a phishing foothold when a directory traversal bug in a logging subsystem hands them unauthenticated code execution outright. Each new critical vCenter or ESXi CVE effectively resets the clock on how fast ransomware crews can go from internet scan to encrypted datastore.
What Comes Next: Five Predictions
- CISA’s KEV catalog will likely add further VMware entries before year-end, given the pace of critical disclosures across vCenter and ESXi in 2025 and 2026.
- Expect ransomware groups to publish victim claims referencing vCenter or ESXi compromise on leak sites within the coming weeks, following the pattern set by earlier hypervisor-targeting campaigns.
- Enterprises will accelerate network segmentation projects that isolate vCenter management interfaces from general-purpose VLANs, treating this disclosure as the forcing function budget requests needed.
- Broadcom will likely face renewed scrutiny over its extended-support model for vCenter 7.0, since customers on that branch cannot self-patch and must wait on direct vendor engagement.
- Cyber insurers are likely to add specific vCenter and ESXi patch-status questions to renewal questionnaires, mirroring how KEV-listed Exchange and Citrix bugs reshaped underwriting after past incidents.
How CVE-2026-59310 Fits the Broader 2026 KEV Pattern
This disclosure is not an isolated event. CISA has been steadily tightening remediation windows across its KEV catalog throughout 2026 in response to a broader increase in disclosure-to-exploitation speed, a trend visible across recent additions covering the agency’s updated Binding Operational Directive deadlines. Other infrastructure-management software has followed a similar arc this year, including a SonicWall SMA1000 flaw that reached KEV status under a comparably tight deadline, and a remote monitoring platform bug that required its fourth fix in five weeks. Ransomware groups have also targeted enterprise software supply chains directly, as seen when Clop exploited a PTC Windchill vulnerability to hit dozens of organizations at once. VMware itself is not new to this cycle either, given a separate VM-escape flaw in VMware Workstation and Fusion disclosed earlier this year. Taken together, these cases point to management-plane software, the tools administrators use to run everything else, becoming the preferred entry point for 2026’s most damaging ransomware campaigns.
Frequently Asked Questions
What is CVE-2026-59310?
CVE-2026-59310 is a critical directory traversal vulnerability in the Syslog server component of VMware vCenter Server. It carries a CVSS score of 9.8 and allows a network-based, unauthenticated attacker to execute arbitrary code on an affected system, as detailed in the National Vulnerability Database entry for the flaw.
Is CVE-2026-59310 being actively exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on August 18, 2026, and confirmed on September 15, 2026, that ransomware gangs are now among the attackers exploiting it, according to BleepingComputer’s reporting. Canada’s Cyber Centre issued a matching security advisory tracking the same flaw.
Which VMware vCenter versions are affected?
Broadcom’s advisory lists vCenter 9.1.x.x, 9.0.x.x (including Cloud Foundation and vSphere Foundation deployments), 8.0, and 7.0 as affected. Fixed builds are 9.1.0.0300, 9.0.2.0100, and 8.0 U3k or 8.0 U2f, respectively. Customers on 7.0 need to contact Broadcom support directly for a fix path.
Is there a workaround if I can’t patch immediately?
Broadcom’s advisory does not list a workaround for CVE-2026-59310. The recommended action is to apply the fixed build. Until that happens, restricting network access to the vCenter management interface to a small, trusted set of hosts reduces exposure.
How does this compare to previous VMware vulnerabilities?
It follows a pattern seen in CVE-2024-37079, CVE-2025-22225, CVE-2025-22226, and CVE-2021-22005, all critical vCenter or ESXi bugs that drew ransomware or in-the-wild exploitation shortly after disclosure. Virtualization management software has become a recurring ransomware target because compromising one server can expose many virtual machines at once.
Does the CISA deadline apply to private companies?
No. The August 21, 2026 remediation deadline applies specifically to U.S. federal civilian executive branch agencies under CISA’s binding operational directive. Private organizations are not legally bound by it, though many security teams treat KEV deadlines as an informal benchmark for urgency.
What should security teams do first?
Confirm the installed vCenter build number, compare it against Broadcom’s fixed versions, patch immediately if affected, and review Syslog service logs for signs of directory traversal attempts or unexpected outbound connections before assuming a system is clean.
