What Happened
Cybersecurity researchers demonstrated a previously unknown vulnerability in VMware ESXi — the software that many organisations and cloud providers use to run multiple virtual computers on a single physical server. The vulnerability allows an attacker who has gained access to one virtual machine to reach across the hypervisor isolation barrier and execute code inside a completely separate virtual machine, even though the two VMs have no legitimate connection to each other.
This was demonstrated live at Pwn2Own Berlin 2026, an internationally recognised security research competition. The researchers earned $200,000 — the highest single-bug award at the event — reflecting the severity and reliability of the exploit.
VMware ESXi has not yet released a patch. The researchers have provided full technical details to Broadcom (VMware’s owner), who has up to 90 days to produce a fix.
Business Impact
For organisations running their own VMware infrastructure (on-premises or private cloud):
If your organisation runs multiple business units, subsidiary companies, or different security-classification workloads on shared VMware ESXi hosts, this vulnerability could allow a breach in one area to reach a completely isolated area on the same physical server. Workloads that are segregated at the network level (different VLANs, firewalls, even air-gaps at the network layer) share the same physical ESXi host in many typical deployments.
For organisations using cloud hosting providers running VMware:
Many cloud and managed hosting providers use VMware ESXi to run customer virtual machines. If your cloud provider uses ESXi-based infrastructure and co-hosts your virtual machines with other customers on shared physical hardware, another customer (or an attacker who has compromised another customer’s VM) could potentially reach your virtual machines at the hypervisor level.
Regulatory implications:
Under GDPR and NIS2, hypervisor-level isolation between tenants is a fundamental technical security measure for systems processing personal data. A demonstrated bypass of that isolation is a significant control failure. Organisations subject to PCI-DSS should assess whether their cardholder data environment uses shared VMware infrastructure and whether isolation guarantees remain met.
Board-Ready Summary
- A security flaw in the virtualisation software used to run company servers allows attackers to jump between isolated virtual machines — essentially, a fence between separated systems that can now be climbed.
- No fix is currently available. The researchers who found the flaw have 90 days to keep the technical details confidential while the vendor develops a patch.
- The immediate risk is to organisations where sensitive and less-sensitive workloads share the same physical server hardware running VMware.
Recommended Actions
- Audit shared-host workloads (this week): Identify any ESXi hosts running virtual machines from different business units, security classifications, or regulated data environments (cardholder data, personal health information, executive communications). These hosts carry the most risk.
- Migrate highest-sensitivity workloads to dedicated physical hosts: Where possible, move the most sensitive VMs to dedicated hardware that does not share an ESXi host with other tenants. This removes the shared-host attack path entirely.
- Contact your cloud or managed hosting provider: Ask your provider whether your VMs share physical ESXi hosts with other customers, and whether they have a mitigation plan for this Pwn2Own disclosure.
- Prepare to patch urgently when Broadcom releases the fix: Set a maximum 72-hour patch window for ESXi updates once the security advisory is published. This is not a standard patching cycle update.
- Monitor VMkernel and ESXi management logs: Unusual connections to the ESXi management interface, unexpected VM configuration changes, or processes spawned from the VMkernel are indicators to investigate.