VMware ESX VMXNET3 out-of-bounds write enables host code execution

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 with VMXNET3 virtual network adapter may exploit this issue to execute code on the host. Non VMXNET3 virtual adapters are not affected by this issue.

• VMware Cloud Foundation: branches 9.1.x.x, 9.0.x.x, and 5.x are recorded as affected. For branch 5.x, Broadcom points to an async patching guide rather than naming a specific fixed release.
• VMware vSphere Foundation: branches 9.1.x.x and 9.0.x.x are recorded as affected. The response matrix maps these deployments to the corresponding ESX fixes.
• VMware ESX: branch 9.1.x.x is affected below ESXi-9.1.0.0200-25557999; branch 9.0.x.x is affected below ESXi-9.0.2.0100-25595025; branch 8.0 is affected below ESXi80U3k-25595708. Broadcom also lists ESXi80U2f-25626445 for the 8.0 U2f track. For 7.0, the advisory directs customers with an extended support contract to contact Broadcom Support and does not name a public fixed release.
• VMware Telco Cloud Platform: branches 5.1.x and 5.0.x are recorded as affected; remediation is directed to KB449886.
• The status of unlisted branches or products must not be inferred from these fixes, including later or parallel branches that were not verified.

VMware ESX contains a memory-safety flaw that performs an out-of-bounds write in the VMXNET3 virtual network adapter. The affected component is the VMXNET3 adapter handling logic, but the available evidence does not identify the specific input, guest operation, descriptor, or code path that causes the invalid write. The vendor describes a malicious actor with local administrative privileges inside a virtual machine configured with VMXNET3, with successful exploitation potentially leading to code execution on the ESX host. This is a cross-boundary outcome that can defeat the intended isolation between guest and host. The normalized scoring metadata records local reachability and changed scope but marks privileges as not required, while the technical description requires local administrative privileges in the virtual machine; use the explicit vendor precondition for operational exposure assessment until that inconsistency is clarified. Non-VMXNET3 virtual adapters are not affected according to the available evidence.

• Reachability: The vendor describes exploitation from inside a virtual machine, not as a direct network attack against the host.
• Preconditions: The attacker is described as having local administrative privileges on a virtual machine using VMXNET3. The normalized privileges field instead records no required privileges, so this aspect is inconsistent and should be handled conservatively.
• Interaction and complexity: The normalized metadata records no user interaction and low complexity, but the advisory does not disclose enough mechanics to independently validate those properties.
• Known exploitation: The supplied record does not identify a public exploit. The returned vulnerability assessment data records exploitation as none at the time of assessment; that status does not establish that exploitation will not occur later.

Successful exploitation may allow code execution on the ESX host from a virtual-machine context, crossing the hypervisor privilege and isolation boundary. The technical consequences may include loss of confidentiality, integrity, or availability for the host and the workloads it manages. In a multi-tenant environment, the impact could extend beyond the initially involved virtual machine, but the available evidence does not confirm a specific path to other virtual machines or management services. The issue is limited to the VMXNET3 virtual network adapter according to the vendor description; other virtual adapters are not affected by the stated flaw.

Successful host code execution could allow an attacker to move beyond the initial virtual-machine context and affect the confidentiality, integrity, or availability of the ESX host. In shared or multi-tenant environments, this could weaken VM isolation and increase the potential blast radius to other workloads on the same host. The available evidence does not establish specific compromise of other virtual machines, stored data, or management services, so those are possible consequences rather than confirmed behavior. The described exposure is limited to virtual machines using VMXNET3; non-VMXNET3 adapters are not affected by this flaw.

1. Inventory all hosts and platform bundles for VMware ESX, VMware Cloud Foundation, VMware vSphere Foundation, and VMware Telco Cloud Platform, and identify virtual machines using VMXNET3.
2. For VMware ESX, update branch 9.1.x.x to ESXi-9.1.0.0200-25557999 or an applicable update containing that fix; update branch 9.0.x.x to ESXi-9.0.2.0100-25595025 or an applicable update containing that fix.
3. For branch 8.0, apply the fix for the active track: ESXi80U3k-25595708 for the U3k track or ESXi80U2f-25626445 for the U2f track. Do not assume that a fix for one track covers the other.
4. For VMware ESX 7.0, contact Broadcom Support if the organization has an extended support contract. For VMware Cloud Foundation 5.x, follow async patching guide KB88287. For VMware Telco Cloud Platform 5.0.x and 5.1.x, follow KB449886.
5. For VMware Cloud Foundation and VMware vSphere Foundation, use the applicable response-matrix entry and apply the corresponding ESX fix for the deployed branch. Do not treat a fix for one branch as evidence about an unverified parallel or later branch.
6. The advisory lists no workaround. If patching cannot be completed immediately, record the exposed hosts and VMXNET3 virtual machines, restrict unnecessary guest administrative access under existing policy, and prioritize the update plan; these measures are not a substitute for the vendor fix.
7. After updating, verify the host build, patch state, and VMXNET3 inventory. Leave branches without a verified response-matrix status as unknown.

1. Inventory VMware ESX, VMware Cloud Foundation, VMware vSphere Foundation, and VMware Telco Cloud Platform deployments, then compare each host with the affected and fixed branches listed in the advisory.
2. Review virtual hardware inventory for every virtual machine and identify which systems use the VMXNET3 adapter. This is the specific exposure condition stated in the vulnerability description.
3. Identify accounts or processes with local administrative privileges inside those virtual machines, because the vendor describes that access as an exploitation precondition.
4. Review patch records and the actual host build to verify that the applicable fix is installed, rather than relying only on a platform bundle being marked patched.
5. No specific log event, IOC, or exploit artifact is supplied. Monitoring for unusual host-side execution, configuration changes, or other anomalous activity may be used as a precaution, but the absence of those signs does not prove that a system is safe.