CVE-2026-47876 lets a VM break out and run code on the ESXi host underneath it. Broadcom patched five bugs at once — and the one graded lower is actually getting all the headlines.
Broadcom just patched five VMware vulnerabilities in one advisory, and the one everyone's writing about — a VM that can break out and run code on its own host — isn't actually the worst bug in the batch. That's CVE-2026-47876, a 9.3-severity VM escape in the VMXNET3 virtual network adapter, confirmed by SecurityWeek. Sitting right next to it, scoring higher at 9.8, is an unauthenticated way to walk straight past vCenter's login screen. The escape makes the better headline. The auth bypass is the one that needs your attention first.
The five bugs, side by side
What Broadcom actually patched
CVE-2026-59309
Component
vCenter Directory Service
CVSS
9.8
What it does
Unauthenticated auth bypass — no login needed
CVE-2026-59310
Component
vCenter Syslog
CVSS
9.8
What it does
Directory traversal leading to remote code execution
CVE-2026-47876
Component
ESX / Workstation / Fusion — VMXNET3
CVSS
9.3
What it does
VM escape — code execution on the host from inside a VM
CVE-2026-41703
Component
ESX / Workstation / Fusion
CVSS
7.6 / 2.7
What it does
Out-of-bounds read, severity differs by product
CVE-2026-41709
Component
ESX
CVSS
2.7
What it does
Insufficient logging
Component
CVSS
What it does
CVE-2026-59309
vCenter Directory Service
9.8
Unauthenticated auth bypass — no login needed
CVE-2026-59310
vCenter Syslog
9.8
Directory traversal leading to remote code execution
CVE-2026-47876
ESX / Workstation / Fusion — VMXNET3
9.3
VM escape — code execution on the host from inside a VM
CVE-2026-41703
ESX / Workstation / Fusion
7.6 / 2.7
Out-of-bounds read, severity differs by product
CVE-2026-41709
ESX
2.7
Insufficient logging
How a VM actually breaks out of its own box
Virtualization's entire pitch rests on one promise: what happens inside a VM stays inside a VM. VMXNET3 is VMware's high-performance virtual network card — the thing translating a guest OS's network calls into something the hypervisor can push onto physical hardware. CVE-2026-47876 is an out-of-bounds write in that translation layer. An attacker who already has administrator rights inside a VM — not the host, just the guest — can corrupt memory in a way that lets them execute code on the ESXi host underneath. That's the nightmare scenario for shared infrastructure: one tenant's VM reaching out and touching everyone else's.
VM escapes matter most on shared hosts — cloud providers, university labs, and anyone running untrusted workloads alongside their own. · Unsplash
Why the 9.8 next to it should worry you more
CVE-2026-59309 doesn't need any of that setup. It's an authentication bypass in vCenter's own Directory Service — the layer that decides who's allowed to log in and manage your entire virtual environment. No VM access, no admin rights inside a guest, nothing. Just network reachability to vCenter itself. That's a lower bar to clear than 'first compromise a VM, then escalate,' which is exactly why it scored higher. If you're triaging which patch to apply first and only have time for one tonight, it isn't the escape.
CVSS score by bug — the escape isn't even the highest
vCenter auth bypass (59309)9.8
Unauthenticated, no VM needed
vCenter syslog RCE (59310)9.8
Directory traversal → RCE
VMXNET3 VM escape (47876)9.3
Needs admin inside a VM first
OOB read (41703)7.6 / 2.7
Varies by affected product
Insufficient logging (41709)2.7
Lowest severity of the five
What's actually fixed, and where
ESXi: update to 9.1.0.0200, 9.0.2.0100, or 8.0 Update 3k, depending on your branch.
vCenter: update to 9.1.0.0300, 9.0.2.0100, or 8.0 Update 3k — same branch logic as ESXi.
Workstation/Fusion on 25H2: upgrade to 26H1 to close CVE-2026-41703.
Can't patch vCenter tonight? Restrict management-network access to it — the auth bypass needs network reachability and nothing else.
Check whether any VM on shared hosts uses VMXNET3 alongside untrusted or lower-trust guests — that's where the escape risk actually concentrates.
These issues qualify under ITIL methodologies as an emergency change, requiring prompt action from your organization.
Broadcom security advisory
VMware VM escape and auth bypass: quick answers
Is any of this being exploited right now?
Broadcom says it has no indication of in-the-wild exploitation for any of the five bugs as of its advisory. That's a real advantage — patch now, before that changes, rather than reacting to a confirmed breach.
Do I need to worry about the VM escape if I only run my own VMs?
Less so. The escape needs administrator access inside a VM first, so the real risk concentrates in shared or multi-tenant hosting — cloud environments, shared labs, anywhere an attacker could compromise one VM and reach for others.
Which bug should I patch first if I can't do everything at once?
The vCenter auth bypass, CVE-2026-59309. It scores the same or higher than the VM escape and needs no prior foothold at all — just network access to vCenter.
Does this affect Workstation or Fusion on a personal PC?
Yes, for CVE-2026-41703 specifically — anyone on Workstation/Fusion 25H2 should move to 26H1. The two 9.8 vCenter bugs and the VM escape are enterprise-server-side issues, not something a home Workstation user needs to lose sleep over beyond that one update.
Virtualization security keeps rhyming across vendors this year — Microsoft's own hypervisor had a comparable moment with the Hyper-V vmswitch privilege escalation bug, and it's been a rough July for enterprise infrastructure generally between the CitrixBleed NetScaler flaw and Oracle's five WebLogic RCEs. The lesson is the same each time: the layer you trust to keep workloads separate is software too, and software has bugs. If you're running anything on shared VMware infrastructure — including a homelab mixing trusted and untrusted VMs on one box — this is worth the maintenance window this week, not next quarter.
