PWN2OWN Berlin 2026: ESXi VM Escape

When the patch doesn’t exist yet, the control still does.

ZeroLock provides mitigating controls for VMware ESXi VM escape exploits like those demonstrated by STARLabs SG at Pwn2Own Berlin 2026.

 

What Happened at Pwn2Own Berlin 2026

Researcher Thach Nguyen Hoang of STARLabs SG demonstrated a memory corruption flaw in VMware ESXi that enabled a full VM escape and cross-tenant code execution. A threat actor with administrative access inside a guest VM could break the isolation boundary, execute code on the underlying ESXi host, and reach virtual machines belonging to other tenants on the same host.

There is no CVE assigned yet. There is no patch yet. Technical details remain embargoed under Pwn2Own disclosure rules. The exploit is real and it works.

 

Why VM Escapes are Different

A typical CVE compromises one workload. A VM escape compromises the substrate. Once an attacker reaches the hypervisor, every tenant on that host is reachable, lateral movement no longer requires network access, and the controls running inside guest VMs become irrelevant. For hosting providers, managed service providers, and any organization running multi-tenant infrastructure, this is the worst class of bug there is.

 

How ZeroLock Mitigates this Exploit Class

VM escapes on ESXi must transit the VMX process. VMX is the userspace process responsible for managing each virtual machine and brokering its interactions with the host. To turn a guest compromise into a host compromise, the exploit has to coerce VMX into doing something it was never meant to do.

ZeroLock’s VMX Lockdown rule constrains what the VMX process is permitted to do on the host. It defines what VMX is allowed to execute, what it is allowed to spawn, and what it is allowed to touch on the host. Behavior outside that envelope is blocked in real time, not flagged after the fact.

That holds for the broad class of VMX-mediated escapes, not just the specific bug demonstrated last week. The control targets the choke point, not the signature.

The traditional approach ZeroLock VMX Lockdown
  • Wait for Broadcom to confirm the vulnerability, ship a patch, and qualify it for your environment.
  • Detection tools see the escape after it succeeds, if at all.
  • Hosts remain exposed during the window between disclosure and patch.
  • Constrains what the VMX process is permitted to do on the host, in real time.
  • Blocks the post-escape behavior that turns a VM compromise into a hypervisor compromise.
  • Mitigation is in place today. No patch required.

 

What to Do Now

  • Deploy ZeroLock and enforce the VMX Lockdown rule on every ESXi host in your estate. ZeroLock is a prerequisite, and the Lockdown rule is the specific control that addresses this exploit class.
  • Reduce administrative blast radius inside guest VMs. The exploit chain assumes admin in guest. Trim privilege where you can.
  • Keep ESXi management interfaces off the internet and restrict them to a hardened management network.
  • Apply Broadcom patches when they ship, but do not wait for them to act.

 

Learn how ZeroLock is deployed in production today to protect ESXi and Linux workloads against the exploits that have not been written yet.