> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # PwnEscape: A Guest VM Read the Host's Memory on Vercel's Sandbox - URL: https://debugly.dev/pwnescape-guest-vm-read-host-memory/ - Published: 2026-10-16T15:00:00.000Z - Updated: 2026-10-17T05:47:49.000Z - Description: A critical Linux kernel flaw lets code inside a VM read the host's memory. A researcher proved it on Vercel's live sandbox and Vercel confirmed the result. - Author: Rohit Bhadani - Tags: Security, DevOps A researcher demonstrated that code running inside a virtual machine can read memory belonging to the host kernel, using a critical flaw in the Linux kernel's memory isolation. The finding, named PwnEscape, was tested against Vercel's live cloud sandbox, and Vercel confirmed the result. The flaw affects the boundary that every cloud provider, every container-as-a-service platform, and every self-hosted hypervisor depends on to keep tenants separate. The details here come from The Hacker News report published 15 October 2026 and Vercel's own confirmation of the demonstration against their production sandbox infrastructure. ## What PwnEscape actually does | Property | What it changes | | ------------ | -------------------------------------------------------------------------------- | | The flaw | A Linux kernel memory isolation bug that lets a guest VM read host kernel memory | | The proof | Demonstrated live against Vercel's cloud sandbox, not just a lab | | The scope | Every platform that runs untrusted code inside a VM on a Linux host | | The severity | Critical: the host memory contains keys, tokens, and data from every tenant | | The status | Disclosed 15 October 2026; vendor confirmation received | The reason a guest-to-host memory read is critical is that the host kernel holds everything the hypervisor does not explicitly isolate: kernel data structures, other tenants' page tables, DMA buffers, and the secrets that the hypervisor loads into memory during boot. A read primitive from inside the guest gives the attacker a window into the host's address space, and the size of that window depends on the specific bug, but even a narrow read is enough to extract encryption keys, session tokens, or the memory layout that defeats KASLR. ## Why Vercel's confirmation matters Vercel's cloud sandbox is a production environment that runs untrusted code for preview deployments, serverless functions, and edge compute. When a researcher demonstrates PwnEscape against a live Vercel sandbox rather than a local VM, the proof carries a different weight: it means the kernel version, the configuration, and the hypervisor setup in production all permit the read. Vercel's confirmation means they saw the result and accepted it as valid. I have tested container escape scenarios against hardened kernel configurations in lab settings, and the gap between a lab PoC and a production demonstration is the gap between "your kernel might be affected" and "your kernel is affected." The PwnEscape demonstration closes that gap for every cloud provider running the same kernel class. ## The container isolation question this answers The GSC data for this site shows steady impressions on queries like "kernel isolation vs container", "hypervisor container isolation", and "container vs microvm isolation", which tells me developers are already asking whether containers and VMs offer the same isolation guarantees. PwnEscape is the answer to that question in the worst possible direction: even a VM, which has a hardware-enforced boundary that containers do not, can be escaped if the kernel has a memory isolation flaw. The distinction that matters is the one I laid out in [the container vs microVM isolation post](https://debugly.dev/container-vs-microvm-isolation/). Containers share the host kernel by design, which means a kernel bug affects them directly. VMs run their own kernel on top of a hypervisor, which adds a layer, but that layer still depends on the host kernel's memory management. PwnEscape is the proof that the extra layer is not a guarantee, and that the host kernel's memory isolation is the real security boundary for every tenant on the machine. ## What changes for platform operators For teams running multi-tenant infrastructure, the practical change is a kernel patch cycle. PwnEscape is a Linux kernel flaw, which means the fix arrives through the kernel's release process, not through a hypervisor update. Every cloud provider, every self-hosted hypervisor, and every container-as-a-service platform that runs on Linux needs to track the kernel patch and apply it. The catch: the kernel patch may not be available yet for every distribution. The disclosure is fresh (15 October), and distribution-specific kernel packages lag behind the upstream fix. Until the patch lands in your kernel package, the mitigations are the same ones that apply to any guest-to-host escape: reduce the attack surface inside the guest, restrict what the guest can access, and assume the host kernel is reachable. ## What I now do Every tenant-isolation model I review now starts from the assumption that the host kernel is the attack surface, not the hypervisor. Containers share the kernel directly. VMs depend on the kernel's memory management. MicroVMs like Firecracker add a VMM layer but still rely on the host kernel for memory allocation. PwnEscape is the demonstration that the kernel is the common denominator, and a flaw in its memory isolation is a flaw in every isolation model built on top of it. The vulnerability will be patched. The lesson will remain: the host kernel is the boundary that matters, and every tenant on the machine shares it. ## What to do right now I ran the checklist against our own multi-tenant infrastructure this morning. The immediate steps are short. First, check the kernel version on every hypervisor host and compare it against the upstream fix. Distribution packages may lag the mainline release by days, and the gap is the exploitation window. Second, review the threat model for any environment that runs untrusted code: preview deployments, serverless functions, CI runners, and user-submitted execution all fall into the category where a guest-to-host read is an attack vector. Third, confirm the host has KASLR, SMEP, and SMAP enabled, because these reduce the value of a read primitive even when the flaw exists. According to The Hacker News, the researcher who disclosed PwnEscape published the demonstration details alongside the Vercel confirmation, giving defenders a concrete reference for testing their own configurations. For Vercel's part, the company confirmed the demonstration and has presumably begun the patch process for its sandbox infrastructure. The fact that the demonstration succeeded on a live production sandbox, rather than a lab VM, is the signal that every other cloud provider running similar infrastructure should treat this as an immediate-priority kernel update. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)