VMware ESXi, Workstation, and Fusion PVSCSI heap overflow may enable host code execution

VMware ESXi, Workstation, and Fusion contain a heap-overflow vulnerability in the PVSCSI (Paravirtualized SCSI) controller that leads to an out-of-bounds write. A malicious actor with local administrative privileges on a virtual machine may exploit this issue to execute code as the virtual machine's VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox and exploitable only with configurations that are unsupported. On Workstation and Fusion, this may lead to code execution on the machine where Workstation or Fusion is installed.

• VMware ESXi: The 8.0 branch is affected below ESXi80U3f-24784735 on the U3 line or below ESXi80U2e-24789317 on the U2 line. The 7.0 branch is affected below ESXi70U3w-24784741.
• VMware Workstation: The 17.x branch is affected below 17.6.4.
• VMware Fusion: The 13.x branch is affected below 13.6.4.
• VMware Cloud Foundation: The 5.x and 4.5.x branches are affected. Broadcom's matrix maps asynchronous remediation to ESXi80U3f-24784735 for 5.x and ESXi70U3w-24784741 for 4.5.x.
• VMware Telco Cloud Platform: The 5.x, 4.x, 3.x, and 2.x branches are affected. Broadcom's matrix maps 5.x and 4.x to ESXi80U3f-24784735, and 3.x and 2.x to ESXi70U3w-24784741.
• VMware Telco Cloud Infrastructure: The 3.x and 2.x branches are affected, with asynchronous remediation mapped to ESXi70U3w-24784741.
• Broadcom's matrix separately lists ESX 9.0.0.0 in VMware Cloud Foundation and VMware vSphere Foundation as unaffected for this issue. The status of branches not listed is not established by this record.

The flaw is a heap overflow in the PVSCSI controller, the Paravirtualized SCSI controller, leading to an out-of-bounds write classified as CWE-787. The virtual storage controller is the exposed attack surface, but the advisory does not identify the exact request, field, or boundary condition that triggers the overwrite. The vendor narrative states that the attacker needs local administrative privileges inside the virtual machine. Successful exploitation may allow code execution as that virtual machine's VMX process on the host. On ESXi, exploitation is contained within the VMX sandbox and is described as possible only with unsupported configurations. On Workstation and Fusion, the result may be code execution on the machine running the product; the precise memory layout and reliable exploitation sequence are not disclosed in the reviewed material.

• Reachability: The documented path is local from a virtual machine and is not described as remotely exploitable.
• Preconditions: The vendor narrative requires local administrative privileges inside the virtual machine. The normalized record characterizes the path as low complexity and requiring no user interaction.
• ESXi scope: Exploitation is described only for unsupported configurations and is contained within the VMX sandbox.
• Workstation and Fusion scope: Exploitation may result in code execution on the machine where Workstation or Fusion is installed.
• Known exploitation: The CISA material included in the research record states that no known public exploitation specifically targeting these vulnerabilities had been reported at the time of its assessment. This does not establish that exploitation cannot occur later.

The described technical outcome is an out-of-bounds write caused by a heap overflow in PVSCSI, which may lead to code execution in the VMX process context on the host. On ESXi, the vendor describes execution as contained within the VMX sandbox and ties exploitation to unsupported configurations. On Workstation and Fusion, code execution may occur on the machine where the software is installed, so the impact can cross the virtual machine boundary. Operationally, a compromised host could affect the confidentiality, integrity, or availability of workloads and data running there. The record does not confirm data theft, persistence, lateral movement, or a specific exploitation campaign.

• For Workstation and Fusion, successful exploitation may extend impact from the virtual machine to the host or workstation running the product, putting the confidentiality, integrity, and availability of that machine at risk.
• For ESXi, the vendor describes the outcome as contained within the VMX sandbox and limited to unsupported configurations, so the confirmed scope is narrower for supported deployments.
• Cloud Foundation and Telco Cloud environments may require coordinated asynchronous ESXi patching, adding maintenance and compatibility work to the remediation process.
• The record establishes possible host-side code execution but does not establish data theft, persistence, spread to other systems, or a specific compromise scenario.

1. Apply Broadcom's branch-specific fixes: ESXi 8.0 U3 to ESXi80U3f-24784735, ESXi 8.0 U2 to ESXi80U2e-24789317, ESXi 7.0 to ESXi70U3w-24784741, Workstation to 17.6.4, and Fusion to 13.6.4.
2. For Cloud Foundation, apply the corresponding asynchronous ESXi update: 5.x to ESXi80U3f-24784735 and 4.5.x to ESXi70U3w-24784741.
3. For Telco Cloud Platform, use the ESXi80U3f-24784735 path for 5.x and 4.x, and the ESXi70U3w-24784741 path for 3.x and 2.x. For Telco Cloud Infrastructure, use the ESXi70U3w-24784741 path for 3.x and 2.x.
4. Broadcom lists no workaround for this issue. While updates are pending, organizations can reduce exposure by limiting local administrative access inside affected virtual machines and avoiding unsupported ESXi configurations where feasible. These are temporary risk-reduction measures, not substitutes for patching.
5. After updating, verify each product and deployment branch against the applicable fixed build. Do not assume that a fix for one branch covers parallel branches that have not been confirmed.

1. Inventory VMware ESXi, Workstation, Fusion, Cloud Foundation, Telco Cloud Platform, and Telco Cloud Infrastructure deployments, then compare installed versions or builds with Broadcom's fixed-version matrix.
2. Identify virtual machines using the PVSCSI controller and review which guest accounts have local administrative privileges.
3. For Cloud Foundation and Telco Cloud products, map the product release to the corresponding underlying ESXi patch because the vendor specifies asynchronous patching for these branches.
4. Review ESXi deployments for unsupported configurations, since the vendor identifies this as a condition for exploitation on ESXi.
5. Review host telemetry for unexpected VMX process behavior or code execution outside normal operations. This is precautionary monitoring, not a vendor-confirmed IOC.
6. Do not treat the absence of suspicious logs as proof of safety; the advisory does not provide a specific log signature or IOC.