The Cybersecurity and Infrastructure Security Agency confirmed on September 15, 2026, that ransomware gangs have joined an already active espionage campaign targeting a critical VMware vCenter Server flaw, according to BleepingComputer. The vulnerability, tracked as CVE-2026-59310, carries a CVSS score of 9.8 and lets an unauthenticated attacker with network access to a vCenter instance execute arbitrary code through the Syslog server component. Broadcom disclosed it in July 2026 alongside a companion vCenter authentication-bypass flaw, CVE-2026-59309, also rated CVSS 9.8, and patched both bugs on July 29, 2026 by rolling the fixes into vCenter 9.1.0.0300, with parallel fixes shipped in 9.0.2.0100 and the 8.0 Update 3k branch — but the fix arrived weeks before most administrators applied it, and that gap is now being paid for in encrypted virtual machines.
What makes the ransomware-era warning different from the initial disclosure is scope. Reporting moved from a single suspected state-linked actor to ransomware gangs, plural, a shift that changes the calculus for every enterprise still running an unpatched vCenter Server. This is a fast-moving story, and the facts below reflect reporting available as of October 25, 2026, part of a broader run of critical infrastructure disclosures we’ve been tracking in our 2026 cybersecurity threats coverage.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What CISA Has Reportedly Confirmed
CISA’s update, reported by BleepingComputer, says ransomware operators have joined attacks against CVE-2026-59310 that were previously attributed to a narrower set of intruders. The agency added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on August 18, 2026, roughly three weeks after Broadcom shipped a patch. Federal civilian agencies were given a remediation deadline of August 21, 2026, which has since passed and was an unusually tight window that signals how seriously CISA weighed the risk of an unauthenticated, network-reachable RCE sitting inside the management plane of most enterprise virtualization stacks.
The vulnerability tracking site cvetodo.com lists CVE-2026-59310 with an EPSS score near 45.9%, meaning security scoring models put it at a roughly even chance of exploitation attempts within days of any KEV listing, a figure that reporting suggests has since been overtaken by events. For a bug living inside vCenter, the management console that controls provisioning, snapshots, and access across an entire virtualization fleet, that probability translated into real intrusions faster than most patch cycles could keep up with.
Inside CVE-2026-59310: How the Flaw Actually Works
Broadcom’s own advisory, as described in coverage from Nopal Cyber’s threat hunting unit, characterizes CVE-2026-59310 as a directory traversal vulnerability in the vCenter Syslog server. Directory traversal bugs typically let an attacker manipulate file paths to reach resources outside an intended directory; in this case, researchers say the flaw can be chained into full remote code execution without any authentication step. That combination, unauthenticated plus RCE plus a component that ships enabled by default on most vCenter deployments, is close to the worst-case profile a virtualization vendor can face.
The affected product is VMware vCenter Server itself, not ESXi hosts directly, though compromising vCenter typically hands an attacker the keys to every ESXi host it manages. Broadcom’s fixed builds, per Nopal Cyber’s advisory, are vCenter 9.1.0.0300 and 9.0.2.0100 (both of which close CVE-2026-59310 together with the companion CVE-2026-59309 authentication bypass in the same release), plus 8.0 update tracks identified as U3k or U2f depending on the branch an organization runs. Administrators on older 7.x branches should treat any instance still in production as a priority patch target, since vCenter 7.x reached end of general support territory well before this disclosure. NVD lists the vCenter 9.1 fix for CVE-2026-59309 and CVE-2026-59310 at version 9.1.0.0300 and the vCenter 9.0 fix at version 9.0.2.0100.
Timeline: From Silent Patch to Ransomware Warning
The sequence of events matters here because it illustrates a pattern security teams have seen before: a quiet patch, a delayed disclosure, then a scramble once exploitation becomes public. Broadcom shipped the fix on July 29, 2026, with an advisory describing the Syslog server flaw in general terms. Roughly three weeks passed before The Hacker News reported on August 17, 2026 that a suspected China-nexus actor was already exploiting the bug, deploying a tool researchers dubbed linuxFile that provided remote command execution capability on compromised hosts. CISA added the CVE to its KEV catalog the very next day, August 18, 2026.
By early September, Nopal Cyber’s Cyber Threat Intelligence Unit reported an active exploitation campaign it said had compromised 361 victim IP addresses across 47 countries, with the intrusion set using access to drop Babuk-derived ransomware directly onto ESXi hosts managed by the compromised vCenter instances. That tracked with what the Cloud Security Alliance had already flagged in August 2026, when it reported active global exploitation of CVE-2026-59310 and listed the same three fixed vCenter branches (9.1.0.0300, 9.0.2.0100, and 8.0 U3k/U2f) named in Broadcom’s advisory. Quirso also reported active exploitation of CVE-2026-59310, rated CVSS 9.8, in August 2026. That campaign detail is what makes the CISA language notable: the agency is no longer described as tracking a single espionage-linked actor but a broader ransomware ecosystem that has since piled onto the same unpatched attack surface.
Who’s Behind the Attacks
Attribution here is layered and still evolving. The Hacker News’s August 17 report pointed to a suspected China-nexus actor as the first confirmed exploiter, using the flaw to plant a remote-access implant rather than immediately deploying ransomware. Subsequent tracking, including the Nopal Cyber advisory, associated later-stage activity against the same CVE with Babuk-derived ransomware payloads landing on ESXi hosts. CISA’s own September 15 statement, per BleepingComputer, does not name a specific ransomware brand but confirms that ransomware gangs broadly have joined the exploitation of CVE-2026-59310, a wording change from earlier advisories that focused on a single intrusion set.
That ambiguity is not unusual for fast-moving KEV updates. CISA’s KEV catalog exists to flag confirmed in-the-wild exploitation to federal agencies and, by extension, the private sector, not to provide definitive attribution. Security teams should treat the “who” as secondary to the “what”: an internet-facing or even internally-facing vCenter instance that hasn’t been patched since July 29 is a live target regardless of which group gets there first.
Why vCenter Is Such an Attractive Ransomware Target
Ransomware crews have increasingly skipped endpoint-by-endpoint encryption in favor of hitting the hypervisor layer directly, and it’s easy to see why. A single compromised vCenter Server can expose credentials, snapshots, and API access spanning dozens or hundreds of virtual machines at once. Encrypting the datastore that backs a VM sidesteps most endpoint detection tools entirely, since the malicious activity happens below the guest operating system rather than inside it. That’s the same structural weakness that made the 2023 ESXiArgs campaign so damaging, and it’s the reason vCenter and ESXi vulnerabilities keep reappearing on the KEV catalog year after year.
Enterprises also tend to under-segment their management networks. vCenter is frequently reachable from broad swaths of internal infrastructure because it needs to talk to every host it manages, which means a single unpatched instance can act as a pivot point into environments that otherwise look well defended. Security teams that treat vCenter like any other application server, rather than as the crown-jewel control plane it actually is, are the ones most exposed when a flaw like CVE-2026-59310 goes public.
CVE-2026-59310 at a Glance
| Detail | Data |
|---|---|
| CVE identifier | CVE-2026-59310 |
| CVSS v3 base score | 9.8 (Critical) |
| EPSS score | ~45.9% (per cvetodo.com KEV tracker) |
| Vulnerability class | Directory traversal leading to unauthenticated RCE |
| Affected component | vCenter Server Syslog service |
| Vendor | Broadcom (VMware) |
| Patch released | July 29, 2026 |
| Fixed builds | vCenter 9.1.0.0300, 9.0.2.0100, 8.0 U3k / U2f |
| Added to CISA KEV catalog | August 18, 2026 |
| Federal remediation deadline | August 21, 2026 |
| First confirmed exploitation reported | August 17, 2026 (The Hacker News, suspected China-nexus actor) |
| Ransomware payload observed | Babuk-derived ransomware deployed on ESXi hosts |
| Early campaign footprint | 361 victim IP addresses across 47 countries (Nopal Cyber, early September 2026) |
| CISA status as of Sept. 15, 2026 | Confirms ransomware gangs now exploiting the flaw |
The Federal Deadline and What It Means for Everyone Else
CISA’s KEV catalog carries legal weight only for federal civilian executive branch agencies, which are bound by Binding Operational Directive 22-01 to remediate listed flaws by the stated deadline. The August 21, 2026 deadline for CVE-2026-59310 gave those agencies just three days from the KEV listing date, a far tighter window than the standard three-week runway CISA typically allows for less urgent entries. That compression is itself a signal: when CISA shortens the remediation clock, it usually reflects either confirmed active exploitation at scale or a component so foundational to enterprise infrastructure that any delay is judged unacceptable.
Private-sector organizations aren’t bound by the directive, but security teams have learned to treat KEV additions as a de facto industry deadline anyway. Even Microsoft moved on its own timeline outside the federal mandate: in August 2026, the company said Azure VMware Solution would upgrade to vCenter 8.0 U3k to close out the VMSA-2026-0006 flaws, a sign that hyperscaler-hosted VMware environments weren’t automatically shielded from this class of bug either. International regulators moved too: Singapore’s Cyber Security Agency added five related CVEs spanning VMware ESX, vCenter, Workstation, and Fusion to its own advisory that same August 2026, underscoring that the exposure reached well beyond the single flagship vCenter flaw. Cyber insurance underwriters, compliance auditors, and incident response retainers increasingly reference KEV status when assessing an organization’s exposure after a breach, meaning a known, patchable, KEV-listed vCenter flaw that goes unpatched can complicate both insurance claims and liability conversations well after the fact. CISA’s own recent KEV additions covering AI-adjacent infrastructure show the agency applying the same urgency calculus to a growing list of software categories, not just virtualization platforms.
Historical Context: This Isn’t VMware’s First Ransomware Crisis
CVE-2026-59310 is the latest entry in a pattern that stretches back years. The most infamous case remains the ESXiArgs campaign of February 2023, which exploited CVE-2021-21974, a heap overflow in the OpenSLP service on ESXi hosts, to mass-encrypt thousands of internet-exposed servers worldwide, largely because organizations left older, unpatched ESXi builds reachable from the open internet. Broadcom kept finding vCenter bugs in the interim, too: in September 2025 it patched CVE-2025-41250, an authenticated SMTP-header flaw rated CVSS 8.5, with SecurityWeek reporting the fix landed across three separate releases — 9.0.1.0, 8.0 U3g, and 7.0 U3w — and, around the same stretch of 2025 advisories, Broadcom also rated a related vCenter flaw, CVE-2025-41241 affecting the 8.0 and 7.0 branches, at a comparatively minor CVSS 4.4. More recently, CISA confirmed in February 2026, per BleepingComputer’s reporting, that CVE-2025-22225, an ESXi sandbox escape flaw, had also been weaponized in ransomware campaigns after its KEV addition.
| Year | CVE | Flaw type | Ransomware activity |
|---|---|---|---|
| 2023 | CVE-2021-21974 | ESXi OpenSLP heap overflow | ESXiArgs campaign mass-encrypted internet-exposed ESXi hosts globally |
| 2026 (Feb) | CVE-2025-22225 | ESXi sandbox escape | CISA confirmed ransomware use following KEV addition |
| 2026 (Aug-Sept) | CVE-2026-59310 | vCenter Syslog directory traversal to RCE | China-nexus actor followed by broader ransomware gang exploitation, per CISA |
The throughline across all three incidents is the same: a patch exists, but the population of exposed, unpatched instances stays large enough, for long enough, that opportunistic and then targeted attackers find it before defenders finish rolling out fixes. Three years after ESXiArgs, the underlying lesson clearly hasn’t fully landed across the VMware customer base. It’s a pattern that shows up well beyond virtualization software too, from the maximum-severity flaws recently disclosed in GitLab and Cisco’s Firewall Management Center, both of which reached CVSS 10.0 and drew rapid ransomware and nation-state interest once details went public.
Market Impact: Broadcom’s Post-Acquisition VMware Faces Another Trust Test
The timing complicates Broadcom’s ongoing effort to stabilize the VMware customer base after its licensing overhaul pushed some enterprises toward alternative hypervisors. A critical, unauthenticated RCE in the product that sits at the center of that customer relationship, now confirmed to be under active ransomware exploitation, gives already-skeptical IT leaders another data point when evaluating renewal terms, even as Broadcom’s October 13, 2026 description of VMware Cloud Foundation stresses centralized identity management, encryption in transit and at rest, and VMware vSphere live patching. Broadcom’s advisory and patch cadence for this flaw were not unusually slow by industry standards, but the three-week gap between patch release and public confirmation of exploitation is the exact window attackers rely on, and it’s a window that keeps repeating across the virtualization industry regardless of vendor.
For managed service providers and hosting companies running vCenter at scale, the exposure compounds. A single vCenter compromise at an MSP can cascade into ransomware deployment across every downstream client tenant sharing that management plane, a scenario that has already played out in prior ESXi-focused ransomware waves and that security researchers widely expect to recur here, echoing how a single credential-based intrusion helped ransomware operators pressure UHSP’s security team during a LockBit incident earlier this year.
Competitive Comparison: How Virtualization Platforms Handle This Risk Differently
vCenter’s exposure is partly architectural. Centralizing management of an entire virtualization fleet behind a single web-facing console creates efficiency for administrators and a single high-value target for attackers, a tradeoff every enterprise hypervisor platform makes in some form. Microsoft’s Hyper-V, by contrast, more commonly integrates with Active Directory and System Center Virtual Machine Manager, spreading privileged access across identity infrastructure that organizations often already harden more aggressively than a standalone appliance. Nutanix’s AHV and Prism Central follow a similar centralized-console model to vCenter and have had their own history of critical advisories, suggesting the risk is closer to an industry-wide pattern than a VMware-specific failing.
Open-source alternatives like Proxmox VE have gained enterprise attention partly on cost grounds following Broadcom’s licensing changes, but a smaller install base also means less attacker attention, not necessarily fewer latent vulnerabilities. The practical takeaway for security teams evaluating any of these platforms is the same regardless of vendor: the management console should never be reachable from the general internet, and network segmentation between the hypervisor control plane and everything else should be treated as non-negotiable, not aspirational.
What Security Teams Should Do Right Now
The remediation path for CVE-2026-59310 is straightforward on paper: upgrade to vCenter 9.1.0.0300, 9.0.2.0100, or the appropriate 8.0 U3k/U2f build, and verify the upgrade actually applied rather than trusting a scheduled maintenance window that may have slipped. Administrators can check their current build version from the vCenter Server Appliance shell before deciding whether they’re exposed.
> shell
Shell access is granted to root
root@vcenter [ ~ ]# vpxd -v
VMware VirtualCenter 9.0.2 build-XXXXXXXX
# Compare the build number against Broadcom's advisory
# for 9.1.0.0300 / 9.0.2.0100 / 8.0 U3k / U2f fixed buildsBeyond patching, incident responders recommend three additional steps for any organization that had an unpatched, internet-reachable, or even broadly internal-network-reachable vCenter instance between July 29 and today: reviewing vCenter and ESXi authentication logs for anomalous sessions since late July, rotating credentials tied to the vCenter Single Sign-On domain, and confirming that ESXi datastore snapshots and backups are stored somewhere the vCenter service account itself cannot reach or delete. That last point matters because ransomware operators targeting hypervisors increasingly hunt for and destroy accessible backups before triggering encryption, a technique observed across the ESXiArgs, CVE-2025-22225, and now CVE-2026-59310 exploitation waves.
Where the vCenter Fixes and Deadline Stand
The August 21, 2026 federal deadline is now a past deadline, so the three-day window described in this story refers to the gap between the August 18 KEV listing and that cutoff, not to a fresh countdown. What remains open is the exposure of any organization that never moved to a fixed build. The fix set Broadcom published on July 29, 2026 is vCenter 9.1.0.0300, 9.0.2.0100, and 8.0 U3k/U2f, and reporting recommends those versions as the baseline.
Guidance now treats CVE-2026-59310 as an emergency patching and exposure-management issue, with the July 29 fixed builds as the minimum confirmed remediation baseline. A related vulnerability, CVE-2026-59309, was also reported in the same incident context, so confirming the build number covers both flaws at once. The product itself has not changed: no confirmed result shows vCenter Server being renamed, retired, or discontinued, and it is still referred to as VMware vCenter Server in vulnerability reporting and Broadcom’s security context.
For administrators, the practical reading is that waiting for further guidance gains nothing. Broadcom’s status history for October 24, 2026 recorded completed maintenance for VMware Avi Cloud Console and VMware Cloud on AWS, but that does not establish the security status of vCenter Server, so each instance still needs its own build check. Teams that already patched should confirm the upgrade actually applied, and teams that have not should treat the work as overdue rather than scheduled.
Predictions: Where This Story Goes From Here
- Expect CISA or Broadcom to issue an updated advisory within days identifying at least one named ransomware group by brand, following the pattern set by prior KEV escalations once attribution firms complete their analysis.
- Additional victim organizations, likely mid-size enterprises and MSPs that deferred patching past the July 29 release, will surface in breach disclosures and ransomware leak-site postings over the following weeks.
- Broadcom will likely face renewed scrutiny over vCenter’s default network exposure and may face pressure to ship stricter default network segmentation guidance or a built-in access-restriction feature in future releases.
- Cyber insurers will increasingly treat unpatched KEV-listed vCenter and ESXi vulnerabilities as a coverage exclusion trigger, mirroring how insurers responded to the ESXiArgs wave in 2023.
- This will not be the last critical vCenter or ESXi flaw to reach the KEV catalog in 2026; the underlying architecture continues to make the hypervisor management layer one of the most consistently targeted categories in enterprise ransomware campaigns.
The Bigger Picture: KEV Fatigue Meets Ransomware Reality
CISA’s KEV catalog now lists well over a thousand vulnerabilities, and security teams juggling limited patching windows have to triage constantly. The risk with a story like CVE-2026-59310 is that it can get lost in that volume, treated as just another line item rather than the kind of flaw that deserves an emergency change window. The combination of a 9.8 CVSS score, an unauthenticated attack path, a component that sits at the center of virtualization infrastructure, and now confirmed ransomware exploitation puts this squarely in the category that should jump every queue, not sit behind routine patch cycles.
It’s also a reminder that KEV listings are lagging indicators. By the time CISA formally confirms ransomware exploitation, as it reportedly did for this flaw, attackers have typically had a working exploit for weeks. Organizations that wait for a KEV addition before treating a critical, publicly disclosed vCenter or ESXi flaw as urgent are, by definition, already behind the attackers who moved the moment Broadcom’s July 29 advisory went live. That gap between disclosure and patch adoption is the same theme running through the industry’s broader 2026 ransomware trend data and the recent Patch Tuesday cycle, both of which point to attackers closing the exploitation window faster than most patch programs can keep pace.
Frequently Asked Questions
What is CVE-2026-59310?
CVE-2026-59310 is a critical directory traversal vulnerability in the VMware vCenter Server Syslog service, carrying a CVSS score of 9.8, that allows an unauthenticated attacker with network access to execute arbitrary code on the affected server. Broadcom disclosed it in July 2026 alongside a companion authentication-bypass flaw, CVE-2026-59309, also rated CVSS 9.8, and fixed both together in vCenter 9.1.0.0300.
Is CVE-2026-59310 being exploited by ransomware right now?
Yes. CISA confirmed on September 15, 2026, that ransomware gangs have joined attacks against the flaw, according to BleepingComputer, following earlier reports of exploitation by a suspected China-nexus actor and a separate campaign linked to Babuk-derived ransomware deployed on ESXi hosts.
Which VMware vCenter versions are affected?
Organizations running vCenter builds prior to the fixed releases are affected. Broadcom’s patched versions are vCenter 9.1.0.0300, 9.0.2.0100, and 8.0 update tracks identified as U3k or U2f, depending on the branch in use.
When was CVE-2026-59310 patched, and when was it added to the CISA KEV catalog?
Broadcom released the patch on July 29, 2026. CISA added the flaw to its Known Exploited Vulnerabilities catalog on August 18, 2026, with a federal civilian agency remediation deadline of August 21, 2026.
Does this vulnerability affect ESXi hosts directly, or only vCenter?
The vulnerability itself resides in vCenter Server’s Syslog service, not ESXi directly. However, since vCenter manages ESXi hosts, attackers who compromise a vulnerable vCenter instance can typically pivot to the ESXi hosts it controls, which is how researchers say ransomware payloads have ultimately landed on ESXi systems in this campaign.
How can I check if my vCenter instance is patched?
Administrators can check their current build from the vCenter Server Appliance shell and compare it against Broadcom’s published fixed versions (9.1.0.0300, 9.0.2.0100, or 8.0 U3k/U2f). If the instance predates those builds, it should be treated as vulnerable and patched immediately.
What ransomware group is behind the attacks?
As of September 15, 2026, CISA’s confirmation, per BleepingComputer, refers to ransomware gangs broadly without naming a specific group for this latest wave. Earlier reporting from The Hacker News attributed initial exploitation to a suspected China-nexus actor, while separate tracking linked a related campaign to Babuk-derived ransomware.
Has a VMware vulnerability been exploited by ransomware before?
Yes. The most notable prior case is the February 2023 ESXiArgs campaign, which exploited CVE-2021-21974 to mass-encrypt thousands of internet-exposed ESXi hosts. CISA also confirmed in February 2026 that CVE-2025-22225, a separate ESXi sandbox escape flaw, had been used in ransomware campaigns.
