A critical out-of-bounds write in the VMXNET3 virtual network adapter lets an attacker with local administrative privileges inside a guest VM execute code on the ESXi host. ZeroLock’s VMX Lockdown rule is designed to constrain that path.
What CVE-2026-47876 does
VMware ESX contains an out-of-bounds write vulnerability in the VMXNET3 virtual network adapter. A malicious actor with local administrative privileges on a virtual machine configured with a VMXNET3 adapter may exploit the flaw to execute code as the VMX process running on the host.
Broadcom rates it Critical, with a CVSS 3.1 score of 9.3.
The affected component matters as much as the score. VMXNET3 is a standard virtual NIC across ESXi estates, so the exposed population is broad rather than niche.
Affected versions:
- 9.1 before ESXi-9.1.0.0200-25557999
- 9.0 before ESXi-9.0.2.0100-25595025
- 8.0 before ESXi80U3k-25595708
- 7.0 and 6.0 — Broadcom does not evaluate products past their End of General Support dates in security advisories, and states that versions not listed in the VMSA should be assumed affected
- 5.0 before KB88287 and KB449886 (VCF and Telco Cloud Program)
Why host-layer code execution changes the calculus
Most critical CVEs compromise a workload. This one compromises the layer the workloads sit on.
Guest-level controls — EDR, host firewalls, privilege boundaries inside the VM — operate above the hypervisor. Once an attacker is executing code as VMX on the ESXi host, those controls are behind them rather than in front of them. The other workloads scheduled on that host are, from an architectural standpoint, within reach of anyone at that layer, and reaching them no longer requires traversing the network or collecting another set of credentials.
For hosting providers, MSPs, and anyone operating shared or multi-tenant infrastructure, that shifts the blast radius from one machine to one host’s worth of machines.
The window between advisory and applied patch
Fixed builds exist for supported versions, and applying them is the durable fix. The practical question is how long the gap stays open.
ESXi patching is a scheduled operation, not a click. Builds get qualified against the environment, workloads get migrated or scheduled into maintenance windows, and hosts roll one at a time. In large estates that timeline runs weeks. In estates with change-freeze periods, availability commitments, or legacy dependencies, it runs longer.
Two situations extend the gap further. Hosts on End of General Support versions have no advisory-driven remediation path at all, and Broadcom’s own guidance is to presume they are affected. And once technical details of a vulnerability circulate publicly, the research cost of building a working exploit drops for everyone, including people who did not disclose responsibly.
Compensating controls exist to cover that interval.
How ZeroLock mitigates this attack vector
The exploit chain runs through VMX. VMX is the userspace process that manages an individual virtual machine and brokers its interactions with the host, and it is the process that handles VMXNET3 device emulation. Turning a guest compromise into host code execution requires coercing VMX into behavior it was never designed to perform.
ZeroLock’s VMX Lockdown rule constrains and monitors VMX process behavior on the hypervisor. It defines what VMX is permitted to execute, what it may spawn, and what it may touch. Activity outside that envelope is blocked as it happens rather than surfaced in a report afterward.
Provided the VMX Lockdown rule is properly configured and enforced, ZeroLock is assessed to detect and respond to this attack vector. ZeroLock additionally monitors for post-exploitation behavior on the ESXi host — the spawning of an interactive shell by a process that has no business spawning one, for instance — which gives a second opportunity to intervene if an attacker reaches the host layer by some other route.
Because the rule governs process behavior rather than matching a known exploit signature, it applies to VMX-mediated escapes as a class. The control sits at the chokepoint the technique has to pass through.
What to do now
Apply the fixed builds. Broadcom’s remediation is the permanent fix, and it belongs in your next maintenance window.
Enforce the VMX Lockdown rule on every ESXi host. ZeroLock deployment is the prerequisite; the Lockdown rule is the specific control that addresses this exploit path. It requires no patch and no modification of underlying system code.
Reduce administrative privilege inside guest VMs. The attack chain assumes local admin in the guest. Every account that does not need those privileges is one fewer starting position.
Keep ESXi management interfaces off the internet. Restrict vCenter and host management to a dedicated management network.
Inventory your unsupported hosts. Anything running past End of General Support should be treated as affected and prioritized either for upgrade or for compensating controls.
ZeroLock deploys to ESXi hosts as a signed VIB and runs with minimal overhead alongside your existing stack. See how ZeroLock protects ESXi and Linux workloads in production today.