Broadcom's advisory, tracked as VMSA-2026-0007 and published on its support portal, fixes two vulnerabilities in VMware Workstation and Fusion. SecurityAffairs' writeup and CyberSecurityNews' coverage both lead with the same detail we'd lead with too: CVE-2026-59346, the critical one, sits in VMXNET3 - the exact virtual network adapter driver where Broadcom fixed a CVSS 9.3 VM escape in ESXi in July's VMSA-2026-0006, which we covered at the time. Different product line, different specific flaw, same component, same severity band, five weeks apart.
What each flaw actually does
CVE-2026-59346 is an integer-overflow bug in VMXNET3 that a user with local administrative privileges inside a guest VM configured with a VMXNET3 adapter can exploit to execute code on the host itself - the textbook definition of breaking out of the sandbox the virtual machine is supposed to provide. CVE-2026-59347, rated important rather than critical at CVSS 8.1, is a stack-based buffer overflow in the Host-Guest File System, the component that handles shared folders between a VM and its host; an attacker with admin rights inside the guest can use it to execute code as the VMX process running on the host. Both require administrative access inside the guest to trigger, which limits casual exploitation, but that's precisely the access level a compromised VM - or a deliberately hostile one, in any environment where VMs run code from parties you don't fully trust - already has by definition.
Desktop virtualisation, not the data centre
It's worth being precise about what VMSA-2026-0007 covers, because it's easy to conflate with the server-side ESXi and vCenter advisories that dominate most vulnerability news out of Broadcom. This one affects VMware Workstation 25H2 and 26H1 on any host operating system, and VMware Fusion 25H2 and 26H1 on macOS - the desktop products developers and engineers run locally to spin up test environments, malware analysis sandboxes, or a second OS on a laptop. The threat model is different from a hyperscale ESXi cluster, but not lower-stakes: a developer running an untrusted or malware sample inside a Workstation VM, or a security analyst detonating a suspicious binary in what they believe is an isolated sandbox, is exactly the scenario this flaw breaks.
Credited researchers, and what that says about who's looking
Broadcom's advisory credits CVE-2026-59346 to researcher h4urek of secsys lab, and separately to Y² and Stan S working through Trend Micro's Zero Day Initiative; CVE-2026-59347 is credited to Yeonghyeon Choi and Tianchu Chen of Tencent's Xuanwu Lab. Independent discovery of the same driver by unconnected research teams, arriving close enough together to land in one advisory, is usually a signal that a component has become a known place to look - which, given VMXNET3's second appearance in a critical VM-escape advisory inside two months, it clearly now is.
What to do about it
- Update VMware Workstation and Fusion to version 26H1u1, which remediates both CVE-2026-59346 and CVE-2026-59347.
- Treat any VM configured with a VMXNET3 adapter as in scope, not just VMs used for untrusted workloads - the adapter is a common default, not a niche configuration.
- If your organisation uses Workstation or Fusion VMs specifically as malware-analysis or untrusted-code sandboxes, prioritise this patch ahead of general desktop software updates, since that use case is precisely where the escape has the most value to an attacker.
- Review Host-Guest File System shared-folder usage and disable it on VMs that don't need it, reducing the CVE-2026-59347 attack surface independently of patching.
- Given VMXNET3's second critical escape finding this year, flag it for closer review anywhere your environment still exposes it unnecessarily, including on ESXi hosts already patched against July's finding.
Two critical VM-escape findings in the same driver inside two months doesn't necessarily mean VMXNET3 is uniquely weak - it may just mean researchers found it interesting after the first one and kept looking, which happens. Either way, the practical response is the same one we set out for July's ESXi advisory: patch promptly, and don't treat "it's just a VM" as a reason to deprioritise. If you'd like help auditing VMXNET3 exposure across your virtualisation estate, email sales@halfteck.com.