The Hypervisor Escape Comes to VMware: CVE-2026-47876 May Let a Guest VM Run Code on the ESX Host

Three times this year the hosting industry has watched a guest-to-host escape land on the KVM side of the fence: ITScape on arm64 in June, then Januscape and Zapscape in the same x86 shadow-paging code. Now it is VMware’s turn. CVE-2026-47876, a critical out-of-bounds write in the VMXNET3 virtual network adapter, may let an attacker with administrative privileges inside a guest virtual machine that uses that adapter execute code on the ESX host itself. Broadcom rates it 9.3 out of 10 and offers no workaround. The fix ships in an advisory that also closes two vCenter flaws rated 9.8. One bypasses authentication with nothing more than network access; the other, a directory traversal, was being exploited in the wild within five days of disclosure. For any provider selling VPS, private cloud or managed infrastructure on vSphere, this is not a routine patch note. It reaches the tenant isolation that vSphere-based hosting products are sold on, and closing it means restarting hosts.

Key facts (verified August 14, 2026)

• CVE-2026-47876 is an out-of-bounds write (CWE-787) in the VMXNET3 virtual network adapter, rated CVSS 9.3 (Critical). A guest administrator on a VM with a VMXNET3 adapter may be able to cross the boundary and run code on the ESX host. Broadcom states that non-VMXNET3 adapters are not affected.
• The same advisory, VMSA-2026-0006, carries two 9.8-rated vCenter flaws: CVE-2026-59309, an authentication bypass reachable with network access alone, and CVE-2026-59310, a directory traversal leading to remote code execution. Two lower-rated issues (CVE-2026-41703, CVE-2026-41709) round out the set of five.
• There are no workarounds for any of the five vulnerabilities. Bleeping Computer reports Broadcom advising against swapping VMXNET3 for another virtual adapter, since other adapters have carried flaws of their own and may reduce performance.
• Fixed builds: ESX 9.1.0.0200 and 9.0.2.0100 (Broadcom renamed ESXi to ESX at version 9), ESXi 8.0 Update 3k or the U2f express patch; vCenter 9.1.0.0300, 9.0.2.0100, and 8.0 U3k or U2f; Workstation and Fusion 26H1. VMware Cloud Foundation 5.x and the affected Telco Cloud products carry separate patching instructions.
• Patching ESX requires a host restart. Broadcom’s Q&A document classifies the advisory as an emergency change and recommends vMotion-based rolling reboots, while noting that ESX Live Patch can cut the disruption where an environment supports it.
• CVE-2026-59310 is under active exploitation. The German firm QUIRSO traced first attacker contact on compromised systems to August 3 and counted as many as 361 victim IP addresses across 47 countries. Broadcom’s Q&A, checked August 14, still reports no known exploitation, and no source reports attacks on the ESX flaw.
• The advisory was published July 29, 2026, and revised August 3. Broadcom credits researchers from STARLabs SG, Atredis Partners and CrowdStrike, among others.

One Advisory, Three Critical Holes

VMSA-2026-0006 is the kind of advisory that forces a triage meeting rather than a ticket. The two vCenter flaws are, on paper, the more severe pair. CVE-2026-59309 allows an attacker with network access to vCenter to bypass authentication entirely, and CVE-2026-59310 turns path manipulation into arbitrary code execution on the same management plane. Both carry a CVSS score of 9.8. A compromised vCenter hands an attacker the management plane for every host it manages: the inventory, the stored service credentials and the control surface. How far that reaches depends on how the estate is segmented, but the blast radius starts at the whole cluster. The mitigating factor is architectural. A vCenter interface that is properly fenced off from customer networks and the public internet is hard to reach, and reaching it is the entire requirement.

The ESX flaw inverts that logic. Broadcom scores it lower, and the attacks reported so far target vCenter, but for multi-tenant operators we would still give it equal weight. CVE-2026-47876 does not require the attacker to reach your management network. It requires them to be your customer. The vulnerable code sits in VMXNET3, the paravirtualized adapter Broadcom recommends for performance on guest operating systems that support it, and a routine choice in production fleets and VM templates. An attacker holding administrative privileges inside their own virtual machine, which on an unmanaged VPS is normally part of the service as sold, may trigger an out-of-bounds write in the adapter’s host-side implementation. Code running on the host then sits below every VM on that hardware. The CVSS vector marks the flaw’s scope as changed, which formalizes only that the damage crosses out of the guest. Broadcom does not detail what privilege that execution carries, so how far a real exploit would reach into co-tenant VMs is not settled by the advisory. The NVD entry carries VMware’s own classification of CWE-787, an out-of-bounds write, alongside that changed-scope vector.

No Workaround, and No Easy Detour

Broadcom’s answer to the obvious first question is unambiguous: there is no configuration change that closes any of the five holes while vulnerable code is running. The obvious second question, whether providers can simply switch guests from VMXNET3 to a different virtual adapter, gets an equally direct answer. Broadcom advises against it, according to Bleeping Computer, on the grounds that alternative virtual adapters have contained security flaws of their own and may reduce performance. In other words, the detour leads through older, less maintained code, and the only road out is the patch.

That patch has a cost measured in operations, not money. vCenter updates restart the management interface without touching workloads, which makes the two 9.8-rated flaws comparatively cheap to fix. ESX is the opposite. Applying the update requires restarting the host. Broadcom’s Q&A document classifies the advisory as an emergency change under ITIL terms and recommends using vMotion to evacuate workloads, patching clusters as a rolling reboot. The same document points to ESX Live Patch as a lower-disruption route where an environment supports it. Fleets with spare capacity and licensed vMotion will absorb that as a scheduling problem. Smaller providers running hosts hot, without headroom to evacuate a machine, face powering customer VMs down during the restart window. That burden lands on the same operators already absorbing Broadcom’s post-acquisition licensing changes, a subject we have covered at length.

One of the vCenter Flaws Is Already Being Exploited

Broadcom’s Q&A document, checked August 14, still reports no information suggesting in-the-wild exploitation of any of the five flaws. Outside reporting has overtaken that statement. On August 12 The Hacker News reported active exploitation of CVE-2026-59310, citing the German security firm QUIRSO, which uncovered the campaign during an incident response engagement. The attack chain showed path traversal consistent with the flaw, followed by a malicious cron job that set up persistence through the reverse_ssh tool. QUIRSO counted as many as 361 unique victim IP addresses across 47 countries, and compromised systems made first contact with the attacker’s domains on August 3, five days after disclosure. Attribution is open: the firm suspects an APT actor, and reads the timing as pointing to the public disclosure rather than prior knowledge as the campaign’s starting point.

The authentication bypass, CVE-2026-59309, sits a step earlier on the same management plane. On August 11 the firm Defused Cyber said its honeypots were logging a spike in scanning against vCenter. The probes it described include version checks via RetrieveServiceContent and walks of the SAML SSO flow, which it called indicative of potential exploitation efforts against that flaw. QUIRSO itself is careful here: its co-founder Denis Szadkowski told The Hacker News there is not enough evidence at this stage to tie the scanning to the intrusion set the firm uncovered. No source reports exploitation or probing of CVE-2026-47876, the ESX flaw this article set out from.

The priority order for providers writes itself, and the exploitation reports sharpen it. Any vCenter reachable from an untrusted network is the first call: patch it or fence it off, because one of its two critical flaws is being exploited now and the other needs nothing beyond network access. The ESX issue remains the risk aimed at multi-tenant operators specifically, because the attacker starts inside a VM they legitimately rent rather than outside the management network. It warrants a scheduled rolling reboot rather than a wait for the next maintenance window. The season’s pattern is hard to miss. Januscape needed only administrator access inside a rented VM. Zapscape put servers running no VMs at all in range wherever /dev/kvm was open to ordinary users, who could spin up a throwaway guest and attack the host kernel from inside it. Now CVE-2026-47876 may let a guest admin reach the host through the adapter Broadcom recommends for performance. That makes four escapes this year across two hypervisor stacks, three of them on KVM. The lesson is the same each time: tenant isolation holds only as far as the current patch level, and this time the price of getting current is a host restart, eased only where Live Patch applies.

About the Data

The advisory identifier, its July 29 publication and August 3 revision, the five CVEs, their CVSS scores, the absence of workarounds, the fixed builds and the researcher credits come from Broadcom’s VMSA-2026-0006.1 advisory, retrieved August 14, 2026. The emergency-change classification, the vMotion and Live Patch guidance and Broadcom’s no-known-exploitation statement, still standing when checked August 14, are from its Q&A document. The CWE-787 classification is VMware’s own, on an NVD record awaiting enrichment. Bleeping Computer supplies the adapter-swap guidance; SecurityWeek corroborates the CVE set. The exploitation and scanning reports originate with QUIRSO and Defused Cyber, relayed by The Hacker News. Details may change.