VMSA-2026-0007: two escapes from a VMware guest, and no configuration that stops them
On 3 September 2026 Broadcom published VMSA-2026-0007, an advisory covering two memory-safety defects in VMware Workstation and VMware Fusion. Both allow code to move from a guest virtual machine to the host, and both are fixed only in the 26H1u1 builds.
The VMXNET3 integer overflow
The first defect is CVE-2026-59346, rated 9.3 on CVSSv3. It is an integer overflow in the VMXNET3 virtual network adapter. An attacker with administrative rights inside a guest that uses a VMXNET3 adapter can send crafted traffic through the virtual NIC and end up executing code on the host, which in effect escapes the virtual machine.
VMXNET3 is not an optional component that most people chose to enable. It is the recommended network adapter for Windows and Linux guests on modern Workstation and Fusion releases, and it appears in the default hardware profile of many existing virtual machines. Local administrative rights inside the guest are the price of entry, and in a lab, a developer workstation or a build runner those rights are routine.
The researchers credited for the find are h4urek of the secsys lab, along with Y² and Stan S of Trend Micro's Zero Day Initiative.
The HGFS stack buffer overflow
The second defect is CVE-2026-59347, rated 8.1. It is a stack buffer overflow in HGFS, the shared-folder file system that maps host directories into a guest. An attacker with administrative rights in the guest can cause the VMware VMX process on the host to execute code with the host user's privileges.
Shared folders are a common convenience feature, and they are frequently left enabled after the initial setup. The consequence here is that the guest administrator's reach extends to the host process that runs the virtual machine.
The find is credited to Yeonghyeon Choi and Tianchu Chen of Tencent Xuanwu Lab.
Why the usual workarounds do not apply
The advisory states that no workaround exists. That is an unusual sentence for a hypervisor bulletin, so it is worth reading carefully. Disabling shared folders does not close the HGFS issue for the purposes of the advisory. Changing the virtual network adapter type does not close the VMXNET3 issue. Broadcom's position is that the vulnerable code paths are present in the affected builds and the only remedy is to move to 26H1u1.
That distinction matters operationally because it removes the option of a configuration change bought for time. Environments that cannot patch on the vendor's schedule are left with compensating controls outside the product, such as restricting who holds administrative rights inside guests, or isolating virtual machines that run untrusted code.
Affected versions
The advisory covers Workstation 25H2 and 26H1 on any host operating system, and Fusion 25H2 and 26H1 on macOS. Fixed builds are limited to 26H1u1 for each product. If the installed build string does not include the update suffix, the host is in scope.
Exploitation status
Broadcom describes both issues as privately reported and states that neither was found through exploitation. There is no mention of in-the-wild activity in the advisory. The gap between a working exploit and a public one is real, but so is the value of a guest-to-host escape on a developer workstation that also holds production credentials, which is a common arrangement.
What to do this week
The upgrade to 26H1u1 is the only vendor-supported fix. Before running it, inventory the hosts that actually run guest workloads and note which of them are used by staff with administrative rights inside guests, since those are the ones where the precondition already exists. Where the upgrade cannot happen immediately, review who has local administrator rights in each guest, and treat a guest that can run untrusted code as if it were on the same trust level as the host.
References
- Broadcom VMSA-2026-0007, VMware Workstation and Fusion updates: https://www.vmware.com/security/advisories/VMSA-2026-0007.html
Top comments (0)