The whole promise of cloud computing rests on one assumption: your virtual machine stays in its lane. A newly disclosed Linux kernel vulnerability called PwnEscape — tracked as CVE-2026-99999 — blows a hole straight through that assumption, allowing code running inside a guest VM to read memory on the physical host underneath it.

That's not a theoretical concern. Researcher-confirmed exploitation against Vercel's live cloud sandboxes — and Vercel's own admission that the attack worked — makes this one of the more unsettling disclosures of the year. If you can read host memory, you're not just leaking your own data. You're potentially reading the memory of every other tenant sharing that machine.

What's actually broken?

The flaw sits in the Linux kernel's networking code, which means it isn't a misconfiguration at one particular cloud provider — it's baked into the shared foundation that most of the world's cloud infrastructure runs on. AWS, GCP, Azure, and every smaller cloud operator running Linux-based hypervisors all need to assess their exposure. The attack surface is wide.

The classic analogy here is apartment buildings: virtualisation is the landlord's promise that thick walls separate every unit. PwnEscape is the discovery that the walls are made of paper, and the tenant next door can hear — and read — everything.

Why cloud multi-tenancy makes this especially bad

In a dedicated server environment, a kernel memory leak is serious but contained. In a multi-tenant cloud environment, the blast radius is fundamentally different. A single compromised or malicious workload — think a rogue container, a CI/CD pipeline runner, or a serverless function — could potentially extract secrets, tokens, or cryptographic material belonging to completely unrelated customers on the same physical host.

Vercel's use case is instructive: their sandboxes run arbitrary user code by design. That's exactly the kind of environment where an attacker could feed in a malicious workload, trigger the flaw, and start reading. The fact that the researcher demonstrated it against a live production system before disclosure is a significant signal that this isn't an edge-case exploit — it works.

What to watch for

Linux kernel patches are already in motion, but patching a kernel across a distributed cloud fleet is not a "push and restart" operation. It requires coordinated maintenance windows, live-patching where possible, and careful orchestration to avoid taking down customer workloads. Expect cloud providers to be tight-lipped about their exposure timelines.

For Australian organisations, this is directly relevant to any workload running on public cloud infrastructure — which in 2026 means most of them. The Australian Signals Directorate's cloud security guidance explicitly calls out hypervisor isolation as a critical control; this finding is a prompt to revisit that assessment with vendors. Organisations running sensitive data under the Privacy Act or SOCI Act should be asking their cloud providers for written confirmation of patch status.

The short version: if your threat model includes data isolation between cloud tenants — and it should — PwnEscape just jumped to the top of your vulnerability watchlist.