VMware ESXi zero-days likely exploited a year before disclosure

Chinese-speaking threat actors used a compromised SonicWall VPN appliance to deliver a VMware ESXi exploit toolkit that seems to have been developed more than a year before the targeted vulnerabilities became publicly known.

In attacks from December 2025 analyzed by Huntress, managed security company, the hackers used a sophisticated virtual machine (VM) escape that likely exploited three VMware vulnerabilities disclosed as zero-days in March 2025.

Of the three bugs, only one received a critical severity score:

• CVE-2025-22226 (7.1 severity score): An out-of-bounds read in HGFS that allows leaking memory from the VMX process
• CVE-2025-22224 (9.3 severity score): A TOCTOU vulnerability in Virtual Machine Communication Interface (VMCI) leading to an out-of-bounds write, allowing code execution as the VMX process
• CVE-2025-22225 (8.2 severity score): An arbitrary write vulnerability in ESXi that allows escaping the VMX sandbox to the kernel

At the time of the disclosure, Broadcom warned that the security issues could be chained by attackers with administrator privileges to escape the VM and gain access to the underlying hypervisor.

However, a new report from Huntress provides clues indicating that vulnerabilities may have been chained into an exploit since at least February 2024.

The researchers found in the PDB paths of exploit binaries a folder named “2024_02_19,” suggesting that the package was developed as a potential zero-day exploit.

C:UserstestDesktop2024_02_19全版本逃逸--交付reportESXI_8.0u3

Furthermore, from the name of the folder, which translates to “All/Full version escape – delivery,” it could be inferred that the intended target was ESXi 8.0 Update 3. 

Huntress assesses that initial access likely came through a compromised SonicWall VPN. The attacker used a compromised Domain Admin account to pivot via RDP to domain controllers, stage data for exfiltration, and run an exploit chain that breaks out of a guest VM into the ESXi hypervisor.

The exploit toolkit involved the following components:

• MAESTRO (exploit.exe) – Coordinates the VM escape by disabling VMware VMCI devices, loading the unsigned exploit driver via KDU, monitoring exploit success, and restoring drivers afterward.
• MyDriver.sys – Unsigned kernel driver that executes the VM escape, including ESXi version detection, VMX memory leakage and corruption, sandbox escape, and deployment of a hypervisor backdoor.
• VSOCKpuppet – ELF backdoor running on the ESXi host that provides command execution and file transfer over VSOCK, bypassing traditional network monitoring.
• GetShell Plugin (client.exe) – Windows VSOCK client used to connect from a guest VM to the compromised ESXi host and interact with the VSOCKpuppet backdoor.

The researchers found more clues pointing to the build date of the toolkit. A PDB path embedded in the ‘client.exe’ binary has a folder named “2023_11_02.”

C:UserstestDesktop2023_11_02vmci_vm_escapegetshellsourceclientx64Releaseclient.pdb

It is possible that the component was “part of a broader vmci_vm_escape toolkit with a getshell component.”

The researchers believe that the threat actor may have a modular approach, where they separate the post-exploitation tools from the exploits. This would allow them to use the same infrastructure and just switch to new vulnerabilities. 

Huntress told BleepingComputer that they are moderately confident that the exploit toolkit leverages the three vulnerabilities that Broadcom disclosed last March. Their assessment is based on the exploit’s behavior, including the use of HGFS for information leak, VMCI for memory corruption, and shellcode escaping to the kernel.

However, they could not confirm with 100% certainty that it’s the same exploitation Broadcom disclosed in its original bulletin on the three zero-days.

Regarding the exploitation timeline and attribution-related observations, Huntress reports that some build paths include simplified Chinese, but there’s also an English-language README, possibly indicating an intention to sell it to or share it with other threat actors.

Huntress comments that this combination likely suggests that the toolkit was developed by a well-resourced developer operating in a Chinese-speaking region.

Although the researchers are highly confident that SonicWall VPN was the initial entry vector, they recommend that organizations apply the latest ESXi security updates and use the provided YARA and Sigma rules for early detection.