[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"public-config":3,"i-flag:ph-4x3":14,"i-flag:us-4x3":19,"i-flag:de-4x3":21,"i-flag:hk-4x3":23,"i-tabler:lifebuoy":25,"i-tabler:timeline":28,"i-tabler:apps":30,"i-tabler:package":32,"i-tabler:circle-half-2":34,"i-tabler:sun":36,"i-tabler:moon":38,"i-tabler:menu-2":40,"i-tabler:user":42,"i-tabler:notebook":44,"i-simple-icons:forgejo":46,"i-tabler:shield-lock":48,"i-tabler:tools":50,"i-tabler:calendar":52,"i-tabler:x":54,"$f20t1gb3id2iqf":56,"i-tabler:arrow-left":121,"i-tabler:tag":123},{"matomo":4,"booking":7,"site":9,"blog":11,"newsletter":12},{"enabled":5,"siteId":6},true,"7",{"enabled":5,"url":8},"https:\u002F\u002Fcal.com\u002Fjdbungart",{"url":10},"https:\u002F\u002Fjdneer.com",{"enabled":5},{"enabled":13},false,{"left":15,"top":15,"width":16,"height":17,"rotate":15,"vFlip":13,"hFlip":13,"body":18},0,640,480,"\u003Cpath fill=\"#0038a8\" d=\"M0 0h640v240H0z\"\u002F>\u003Cpath fill=\"#ce1126\" d=\"M0 240h640v240H0z\"\u002F>\u003Cpath fill=\"#fff\" d=\"M415.7 240L0 480V0\"\u002F>\u003Cpath fill=\"#fcd116\" d=\"M26.7 42.4L41 55l16.6-9.2l-7.4 17.5l14 13l-19-1.6l-8.1 17.2l-4.3-18.5L14 71l16.3-10zm323.8 172.3l.4 19l18 6.3l-18 6.2l-.4 19l-11.5-15.1l-18.2 5.5l10.8-15.6l-10.8-15.6l18.2 5.5zM37.2 388.1l8 17.2l19-1.6l-13.9 13l7.4 17.5l-16.6-9.1l-14.4 12.4l3.6-18.7L14 409l18.9-2.4zm114.2-249l-6.2 6.2l3.1 47l-3 .3l-5.7-42.9l-5.1 5l7.6 38.4a48 48 0 0 0-17.2 7.1l-21.7-32.4H96l26.4 34.3l-2.4 2l-31.1-35.5h-8.8v8.8l35.4 31l-2 2.5l-34.3-26.3v7.1l32.5 21.7q-5.2 7.8-7.1 17.2L66.3 223l-5.1 5l42.9 5.7q-.3 1.6-.3 3.1l-47-3l-6.2 6.2l6.2 6.2l47-3.1l.3 3.1l-42.9 5.7l5 5l38.4-7.6a48 48 0 0 0 7.1 17.2l-32.5 21.7v7.2l34.3-26.3l2 2.4l-35.4 31v8.8H89l31-35.4l2.5 2L96 312.2h7.2l21.7-32.5q7.8 5.2 17.2 7.1l-7.6 38.4l5 5l5.7-42.9q1.5.3 3.1.3l-3 47l6.1 6.2l6.3-6.2l-3.1-47l3-.3l5.7 43l5.1-5.1l-7.6-38.4a48 48 0 0 0 17.2-7.1l21.7 32.5h7.2l-26.4-34.3l2.4-2l31.1 35.4h8.8v-8.8l-35.4-31l2-2.4l34.3 26.3v-7.2l-32.5-21.7q5.2-7.8 7.1-17.2l38.3 7.6l5.1-5l-42.9-5.7q.3-1.5.3-3.1l47 3l6.2-6.1l-6.2-6.2l-47 3l-.3-3l42.9-5.7l-5-5l-38.4 7.5a48 48 0 0 0-7.1-17.2l32.5-21.7v-7.1l-34.3 26.3l-2-2.4l35.4-31v-8.9H214l-31 35.5l-2.5-2l26.4-34.3h-7.2L178 200.2q-7.8-5.2-17.2-7.1l7.6-38.3l-5-5l-5.7 42.8l-3.1-.3l3-47z\"\u002F>",{"left":15,"top":15,"width":16,"height":17,"rotate":15,"vFlip":13,"hFlip":13,"body":20},"\u003Cpath fill=\"#bd3d44\" d=\"M0 0h640v480H0\"\u002F>\u003Cpath stroke=\"#fff\" stroke-width=\"37\" d=\"M0 55.3h640M0 129h640M0 203h640M0 277h640M0 351h640M0 425h640\"\u002F>\u003Cpath fill=\"#192f5d\" d=\"M0 0h364.8v258.5H0\"\u002F>\u003Cmarker id=\"SVGEq3dreKJ\" markerHeight=\"30\" markerWidth=\"30\">\u003Cpath fill=\"#fff\" d=\"m14 0l9 27L0 10h28L5 27z\"\u002F>\u003C\u002Fmarker>\u003Cpath fill=\"none\" marker-mid=\"url(#SVGEq3dreKJ)\" d=\"m0 0l16 11h61h61h61h61h60L47 37h61h61h60h61L16 63h61h61h61h61h60L47 89h61h61h60h61L16 115h61h61h61h61h60L47 141h61h61h60h61L16 166h61h61h61h61h60L47 192h61h61h60h61L16 218h61h61h61h61h60z\"\u002F>",{"left":15,"top":15,"width":16,"height":17,"rotate":15,"vFlip":13,"hFlip":13,"body":22},"\u003Cpath fill=\"#fc0\" d=\"M0 320h640v160H0z\"\u002F>\u003Cpath fill=\"#000001\" d=\"M0 0h640v160H0z\"\u002F>\u003Cpath fill=\"red\" d=\"M0 160h640v160H0z\"\u002F>",{"left":15,"top":15,"width":16,"height":17,"rotate":15,"vFlip":13,"hFlip":13,"body":24},"\u003Cpath fill=\"#ec1b2e\" d=\"M0 0h640v480H0\"\u002F>\u003Cpath id=\"SVG5tfvBPpj\" fill=\"#fff\" d=\"M346.3 103.1C267 98 230.6 201.9 305.6 240.3c-26-22.4-20.6-55.3-10.1-72.4l1.9 1.1c-13.8 23.5-11.2 52.7 11.1 71c-12.7-12.3-9.5-39 12.1-48.9s23.6-39.3 16.4-49.1q-14.7-25.6 9.3-38.9M307.9 164l-4.7 7.4l-1.8-8.6l-8.6-2.3l7.8-4.3l-.6-8.9l6.5 6.1l8.3-3.3l-3.7 8.1l5.6 6.8z\"\u002F>\u003Cuse href=\"#SVG5tfvBPpj\" transform=\"rotate(72 312.5 243.5)\"\u002F>\u003Cuse href=\"#SVG5tfvBPpj\" transform=\"rotate(144 312.5 243.5)\"\u002F>\u003Cuse href=\"#SVG5tfvBPpj\" transform=\"rotate(216 312.5 243.5)\"\u002F>\u003Cuse href=\"#SVG5tfvBPpj\" transform=\"rotate(288 312.5 243.5)\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":27},24,"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Cpath d=\"M8 12a4 4 0 1 0 8 0a4 4 0 1 0-8 0\"\u002F>\u003Cpath d=\"M3 12a9 9 0 1 0 18 0a9 9 0 1 0-18 0m12 3l3.35 3.35M9 15l-3.35 3.35m0-12.7L9 9m9.35-3.35L15 9\"\u002F>\u003C\u002Fg>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":29},"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Cpath d=\"m4 16l6-7l5 5l5-6\"\u002F>\u003Cpath d=\"M14 14a1 1 0 1 0 2 0a1 1 0 1 0-2 0M9 9a1 1 0 1 0 2 0a1 1 0 1 0-2 0m-6 7a1 1 0 1 0 2 0a1 1 0 1 0-2 0m16-8a1 1 0 1 0 2 0a1 1 0 1 0-2 0\"\u002F>\u003C\u002Fg>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":31},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M4 5a1 1 0 0 1 1-1h4a1 1 0 0 1 1 1v4a1 1 0 0 1-1 1H5a1 1 0 0 1-1-1zm0 10a1 1 0 0 1 1-1h4a1 1 0 0 1 1 1v4a1 1 0 0 1-1 1H5a1 1 0 0 1-1-1zm10 0a1 1 0 0 1 1-1h4a1 1 0 0 1 1 1v4a1 1 0 0 1-1 1h-4a1 1 0 0 1-1-1zm0-8h6m-3-3v6\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":33},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"m12 3l8 4.5v9L12 21l-8-4.5v-9zm0 9l8-4.5M12 12v9m0-9L4 7.5m12-2.25l-8 4.5\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":35},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M3 12a9 9 0 1 0 18 0a9 9 0 1 0-18 0m9-9v18m0-7l7-7m-7 12l8.5-8.5M12 9l4.5-4.5\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":37},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M8 12a4 4 0 1 0 8 0a4 4 0 1 0-8 0m-5 0h1m8-9v1m8 8h1m-9 8v1M5.6 5.6l.7.7m12.1-.7l-.7.7m0 11.4l.7.7m-12.1-.7l-.7.7\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":39},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M12 3h.393a7.5 7.5 0 0 0 7.92 12.446A9 9 0 1 1 12 2.992z\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":41},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M4 6h16M4 12h16M4 18h16\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":43},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M8 7a4 4 0 1 0 8 0a4 4 0 0 0-8 0M6 21v-2a4 4 0 0 1 4-4h4a4 4 0 0 1 4 4v2\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":45},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M6 4h11a2 2 0 0 1 2 2v12a2 2 0 0 1-2 2H6a1 1 0 0 1-1-1V5a1 1 0 0 1 1-1m3 0v18m4-14h2m-2 4h2\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":47},"\u003Cpath fill=\"currentColor\" d=\"M16.777 0a2.9 2.9 0 1 1-2.529 4.322H12.91a4.266 4.266 0 0 0-4.265 4.195v2.118a7.08 7.08 0 0 1 4.147-1.42l.118-.002h1.338a2.9 2.9 0 0 1 5.43 1.422a2.9 2.9 0 0 1-5.43 1.422H12.91a4.266 4.266 0 0 0-4.265 4.195v2.319A2.9 2.9 0 0 1 7.222 24A2.9 2.9 0 0 1 5.8 18.57V8.589a7.11 7.11 0 0 1 6.991-7.108l.118-.001h1.338A2.9 2.9 0 0 1 16.778 0M7.223 19.905a1.194 1.194 0 1 0 0 2.389a1.194 1.194 0 0 0 0-2.389m9.554-10.464a1.194 1.194 0 1 0 0 2.389a1.194 1.194 0 0 0 0-2.39m0-7.735a1.194 1.194 0 1 0 0 2.389a1.194 1.194 0 0 0 0-2.389\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":49},"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Cpath d=\"M12 3a12 12 0 0 0 8.5 3A12 12 0 0 1 12 21A12 12 0 0 1 3.5 6A12 12 0 0 0 12 3\"\u002F>\u003Cpath d=\"M11 11a1 1 0 1 0 2 0a1 1 0 1 0-2 0m1 1v2.5\"\u002F>\u003C\u002Fg>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":51},"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Cpath d=\"M3 21h4L20 8a1.5 1.5 0 0 0-4-4L3 17zM14.5 5.5l4 4\"\u002F>\u003Cpath d=\"M12 8L7 3L3 7l5 5M7 8L5.5 9.5M16 12l5 5l-4 4l-5-5m4 1l-1.5 1.5\"\u002F>\u003C\u002Fg>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":53},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M4 7a2 2 0 0 1 2-2h12a2 2 0 0 1 2 2v12a2 2 0 0 1-2 2H6a2 2 0 0 1-2-2zm12-4v4M8 3v4m-4 4h16m-9 4h1m0 0v3\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":55},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M18 6L6 18M6 6l12 12\"\u002F>",{"slug":57,"title":58,"excerpt":59,"image":60,"publishedAt":61,"topics":62,"readMinutes":69,"html":70,"metaTitle":58,"metaDescription":71,"shareImage":72,"updatedAt":61,"author":76,"related":79},"pwnescape-how-crafted-packets-let-a-linux-vm-read-its-hosts-memory","PwnEscape (CVE-2026-99999): A Linux IPv4 Stack Bug Lets a VM Escape to Its Host","PwnEscape (CVE-2026-99999) is a critical bug in the Linux host's IPv4 stack, not KVM, that lets a guest VM read host memory, crash the host and, in the lab, run code on it. Proxmox, Debian and Fedora have fixes, but they only help after a reboot.","\u002Fcontent\u002Fimages\u002F2026\u002F10\u002Fpwnescape_cve_2026_99999_advisory.png","2026-10-20T14:00:00.000+08:00",[63,66],{"key":64,"label":65},"advisories","Advisories",{"key":67,"label":68},"security","Security",8,"\u003Cp>For years, the deal behind every cloud server has been simple: whatever runs inside your virtual machine stays inside your virtual machine. A newly disclosed Linux kernel flaw nicknamed PwnEscape breaks that promise in a way that should get every hypervisor admin's attention. Using nothing more than carefully crafted network packets, code running inside a guest VM could read the host's memory, crash the host, and in a lab setting take full administrator control of it.\u003C\u002Fp>\u003Cp>The bug is tracked as \u003Ca href=\"https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2026-99999&ref=ghost.jdneer.com\">CVE-2026-99999\u003C\u002Fa>. The Linux kernel CVE Numbering Authority (CNA), which assigned it, rates it 9.3 out of 10, or Critical, in the \u003Ca href=\"https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2026-99999&ref=ghost.jdneer.com\">CVE record on cve.org\u003C\u002Fa>. That score comes from the kernel CNA, not from NVD. As of October 19, the U.S. National Vulnerability Database lists the entry as \"Received\" and has not published its own score, and CISA's SSVC assessment in the NVD entry records exploitation as \"none.\"\u003C\u002Fp>\u003Cp>PwnEscape came out of a two-week challenge Vercel ran in August, inviting researchers to break out of Vercel Sandbox for up to $1 million in total rewards. According to \u003Ca href=\"https:\u002F\u002Fvercel.com\u002Fblog\u002Ffindings-from-the-1-million-dollar-vercel-sandbox-challenge?ref=ghost.jdneer.com\">Vercel's write-up of the results\u003C\u002Fa>, the company received 1,285 reports and paid $242,000 in bounties. The single most important report arrived on day three from Paulos Yibelo of the security firm pwn.ai, who was working from a standard sandbox with no special access.\u003C\u002Fp>\u003Cp>Vercel says the host memory leak was demonstrated against its production sandboxes. The crash and code execution attacks were shown on the researcher's own KVM and Firecracker machines, configured to match Vercel's setup. Vercel also says no report in the challenge showed anyone accessing customer data. pwn.ai has published \u003Ca href=\"https:\u002F\u002Fpwn.ai\u002Fblog\u002Fpwnescape?ref=ghost.jdneer.com\">a detailed technical write-up\u003C\u002Fa>, also posted to the \u003Ca href=\"https:\u002F\u002Fwww.openwall.com\u002Flists\u002Foss-security\u002F2026\u002F10\u002F15\u002F5?ref=ghost.jdneer.com\">oss-security mailing list\u003C\u002Fa>, and told \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F10\u002Fcritical-pwnescape-linux-kernel.html?ref=ghost.jdneer.com\">The Hacker News\u003C\u002Fa> that the work was done with an AI-assisted research setup, with human researchers directing it and checking the results on systems they controlled.\u003C\u002Fp>\u003Cp>The flaw lives in an unglamorous corner of the kernel: checksum offloading. To save CPU time, a network packet can arrive with a note that effectively says \"the checksum still needs to be filled in, starting at this offset.\" The kernel fills it in later, just before the packet leaves.\u003C\u002Fp>\u003Cp>The problem, as described in the \u003Ca href=\"https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2026-99999&ref=ghost.jdneer.com\">CVE record\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fpwn.ai\u002Fblog\u002Fpwnescape?ref=ghost.jdneer.com\">pwn.ai's analysis\u003C\u002Fa>, is that a malicious guest gets to choose that offset. A microVM hands the host a packet through its virtual network card, and the host passes it into its own IPv4 stack. The kernel checks the IPv4 header, makes decisions based on it, and only afterward completes the checksum. If the guest pointed the checksum offset into the IPv4 header itself, that late write quietly changes a header the kernel already trusted, including the field that says how long the header is.\u003C\u002Fp>\u003Cp>When the host then fragments the packet, it believes the new, bigger header length and copies bytes from beyond the real packet into the outgoing fragments. That is the leak. According to \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F10\u002Fcritical-pwnescape-linux-kernel.html?ref=ghost.jdneer.com\">The Hacker News\u003C\u002Fa>, each packet could carry back roughly 32 bytes of host memory, and the guest could keep it going for as long as it kept sending. The same kind of corruption, pushed further, produced the crash and the code execution results.\u003C\u002Fp>\u003Cp>pwn.ai calls this \"an entirely new class of attacks in Linux networking,\" and that is a big part of why this one stands out. It is not a bug in Firecracker or in Vercel's configuration. pwn.ai said it found no misconfiguration in Vercel's sandbox at all. The weakness sits in the host kernel's networking code, which is the shared layer nearly every cloud uses to keep tenants apart. Despite the \"KVM escape\" label it picked up on the \u003Ca href=\"https:\u002F\u002Fwww.openwall.com\u002Flists\u002Foss-security\u002F2026\u002F10\u002F15\u002F5?ref=ghost.jdneer.com\">oss-security list\u003C\u002Fa>, the bug is not in KVM or the hypervisor either. The \u003Ca href=\"https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2026-99999&ref=ghost.jdneer.com\">CVE record\u003C\u002Fa> places it in the host\\'s IPv4 stack: guest packets written to the host TAP device are handed by \u003Ccode>tun_get_user()\u003C\u002Fcode> to IPv4, and when \u003Ccode>ip_do_fragment()\u003C\u002Fcode> calls \u003Ccode>skb_checksum_help()\u003C\u002Fcode>, the checksum write lands in an IPv4 header that was already routed and validated. Guests are simply the easiest way to feed that path packets with bad checksum metadata. As Vercel put it, \"almost every major cloud provider isolates customer workloads on this same layer of the Linux kernel, so any defect is shared-infrastructure risk.\"\u003C\u002Fp>\u003Cp>The \u003Ca href=\"https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2026-99999&ref=ghost.jdneer.com\">CVE record\u003C\u002Fa> lists the affected range as starting with Linux 2.6.27, which dates back to 2008.\u003C\u002Fp>\u003Cp>The record scores the attack vector as local. That matters. Someone on the open internet cannot trigger PwnEscape by throwing packets at your server. The attacker needs to be running code inside a guest that sends traffic through a virtual network device the host processes. The record's own scenario describes a malicious microVM whose packets flow through the host's TAP interface, and it notes the attacker needs no host credentials and no action from a host administrator or anyone else.\u003C\u002Fp>\u003Cp>In practice, that puts the following at the front of the line:\u003C\u002Fp>\u003Cul>\u003Cli>Cloud and hosting providers, plus anyone selling VMs or sandboxes to strangers, since untrusted code inside a guest is the whole business model.\u003C\u002Fli>\u003Cli>KVM and Firecracker hosts in general, including the platforms that run AI agents and code in disposable microVMs.\u003C\u002Fli>\u003Cli>Proxmox VE and other KVM-based virtualization clusters, especially where different teams, customers, or students share the same hosts.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>A small home lab running only your own VMs faces much lower real-world risk, but the fix is the same, and it is not worth skipping. PwnEscape is not on CISA's Known Exploited Vulnerabilities (KEV) list, and there is no evidence of attacks in the wild. A public proof of concept for the memory-leak part exists, but no full escape exploit has been published. The \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FPeronGH\u002FCVE-2026-99999?ref=ghost.jdneer.com\">proof of concept\u003C\u002Fa>, posted on GitHub on October 17, exercises the host-memory disclosure step on a prepared lab interface; its author says it reproduces on kernel 6.18.54 and that 6.18.57 fixes it. Turning that leak into a working escape is the harder step, and pwn.ai does not expect it to stay out of reach for long: in its \u003Ca href=\"https:\u002F\u002Fpwn.ai\u002Fblog\u002Fpwnescape?ref=ghost.jdneer.com\">write-up\u003C\u002Fa>, pwn.ai says it expects \"exploits in weaker configurations to arrive in weeks, and exploits working in default hypervisor configurations to arrive in under a month.\"\u003C\u002Fp>\u003Cp>The upstream fix is a single commit, \u003Ca href=\"https:\u002F\u002Fgit.kernel.org\u002Fstable\u002Fc\u002F6785011f8b16abf40b1e9d8b2e332232b3e68822?ref=ghost.jdneer.com\">6785011f8b16, \"ipv4: validate checksum_start before completing checksum,\"\u003C\u002Fa> by Red Hat's Michael S. Tsirkin. It adds a check that the checksum start cannot point inside the IPv4 header, and puts that check in front of checksum completion in five places, including IP fragmentation, netfilter's NFQUEUE and CHECKSUM paths, bridge conntrack, and IPsec output. The commit message is candid that this is \"a defence in depth measure\" and that \"a more complete validation at input is forthcoming, but needs more work.\"\u003C\u002Fp>\u003Cp>The fix has been backported to the stable kernels, as \u003Ca href=\"https:\u002F\u002Flwn.net\u002FArticles\u002F1100611\u002F?ref=ghost.jdneer.com\">LWN's stable kernel coverage\u003C\u002Fa> notes. According to the \u003Ca href=\"https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2026-99999&ref=ghost.jdneer.com\">CVE record\u003C\u002Fa>, these are the first fixed versions in each branch: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, and 7.2.11, with mainline fixed as of 7.3-rc7.\u003C\u002Fp>\u003Cp>Distributions have started shipping it. As of October 19:\u003C\u002Fp>\n\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Platform\u003C\u002Fth>\u003Cth>Fixed kernel\u003C\u002Fth>\u003Cth>Advisory\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Proxmox VE 9\u003C\u002Ftd>\u003Ctd>7.0.14-24-pve\u003C\u002Ftd>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fforum.proxmox.com\u002Fthreads\u002Fproxmox-virtual-environment-security-advisories.149331\u002F?ref=ghost.jdneer.com\">PSA-2026-00068-1\u003C\u002Fa>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Debian 13 trixie\u003C\u002Ftd>\u003Ctd>linux 6.12.113-1\u003C\u002Ftd>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-99999?ref=ghost.jdneer.com\">DSA-6568-1\u003C\u002Fa>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Debian 12 bookworm\u003C\u002Ftd>\u003Ctd>linux 6.1.190-1\u003C\u002Ftd>\u003Ctd>\u003Ca href=\"https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-99999?ref=ghost.jdneer.com\">DLA-4841-1\u003C\u002Fa>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Fedora 43, 44, 45\u003C\u002Ftd>\u003Ctd>kernel 7.2.11\u003C\u002Ftd>\u003Ctd>stable updates repo\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\n\n\u003Cp>Proxmox's advisory, dated October 16, says incomplete validation of checksum metadata \"allowed an attacker to read host memory and write host kernel memory via the virtio network stack, allowing an escape from inside a KVM guest.\" Fedora's 7.2.11 builds sit in the F43, F44 and F45 updates repositories, matching the upstream 7.2.11 fix.\u003C\u002Fp>\u003Cp>Here is the part that is easy to miss. Installing a patched kernel package does nothing until the host actually boots into it. Until every host is rebooted onto the fixed kernel, a guest running on it can still read that host's memory. Updating the kernel inside a guest does not protect the host either. If you can, live-migrate VMs off each node, reboot it onto the new kernel, confirm, and move on to the next. The sources offer no standalone workaround for the flaw itself.\u003C\u002Fp>\u003Cp>For Proxmox VE 9, Proxmox's 7.0.14-24 kernel (Oct 9) includes fixes matching the upstream patch, according to the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fproxmox\u002Fpve-kernel\u002Fblob\u002Fmaster\u002Fdebian\u002Fchangelog?ref=ghost.jdneer.com\">pve-kernel changelog\u003C\u002Fa>. An earlier build, 7.0.14-22 (Oct 6), had already blocked the guest-to-host path by dropping guest packets whose checksum start points into the IP header when the host needs to fragment them. To patch a Proxmox VE 9 host, run \u003Ccode>apt update && apt full-upgrade\u003C\u002Fcode>, reboot the host, and then check that \u003Ccode>uname -r\u003C\u002Fcode> shows 7.0.14-24-pve or newer. Patching the host is what matters here; updating the guests does not fix it.\u003C\u002Fp>\u003Cp>Proxmox VE 8 users should not wait for a 6.8 kernel fix. According to the \u003Ca href=\"https:\u002F\u002Fpve.proxmox.com\u002Fwiki\u002FFAQ?ref=ghost.jdneer.com\">Proxmox VE FAQ\u003C\u002Fa>, PVE 8 reached end of life in August 2026, and Proxmox's PSA-2026-00068-1 lists only the PVE 9 kernel, 7.0.14-24, as fixed. The way out is to upgrade to PVE 9, following Proxmox's \u003Ca href=\"https:\u002F\u002Fpve.proxmox.com\u002Fwiki\u002FUpgrade_from_8_to_9?ref=ghost.jdneer.com\">8 to 9 upgrade guide\u003C\u002Fa>, and to use the hardening steps below only as a stopgap until that is done.\u003C\u002Fp>\u003Ch2 id=\"are-you-affected\">Are you affected?\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cstrong>Do you run untrusted or shared guests on Linux KVM or Firecracker hosts?\u003C\u002Fstrong> That is the exposed case. Every kernel from 2.6.27 up to the fixed releases is in the affected range.\u003C\u002Fli>\u003Cli>\u003Cstrong>Still on Proxmox VE 8?\u003C\u002Fstrong> PVE 8 is past end of life and its 6.8 kernel is not listed as fixed. Upgrade to PVE 9. Until then, as a stopgap, limit untrusted guests on those hosts and keep nested virtualization off.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>Patch and reboot.\u003C\u002Fstrong> On Proxmox VE 9 or Debian:\u003C\u002Fp>\u003Cpre>\u003Ccode>apt update && apt full-upgrade\nreboot\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>Then run \u003Ccode>uname -r\u003C\u002Fcode> again to confirm the new kernel is running.\u003C\u002Fp>\u003Cp>\u003Cstrong>Fedora and other dnf-based systems:\u003C\u002Fstrong> ask the package manager directly.\u003C\u002Fp>\u003Cpre>\u003Ccode>sudo dnf updateinfo list --cve CVE-2026-99999\nsudo dnf needs-restarting -r\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>\u003Cstrong>Debian:\u003C\u002Fstrong> check the installed kernel package against the table above, and whether a reboot is pending:\u003C\u002Fp>\u003Cpre>\u003Ccode>dpkg -l 'linux-image*' | grep ^ii\nsudo needrestart -k\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>\u003Cstrong>Proxmox VE:\u003C\u002Fstrong> confirm the installed and booted kernel.\u003C\u002Fp>\u003Cpre>\u003Ccode>pveversion -v | grep proxmox-kernel\nproxmox-boot-tool kernel list\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>PVE 9 hosts need 7.0.14-24-pve or newer, booted.\u003C\u002Fp>\u003Cp>\u003Cstrong>Check the running kernel on each host\u003C\u002Fstrong>, not the guests:\u003C\u002Fp>\u003Cpre>\u003Ccode>uname -r\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>Start on each host, not inside the guests. Run \u003Ccode>uname -r\u003C\u002Fcode> to see which kernel is actually running, and compare it with the kernel you most recently installed. If they differ, the host is waiting on a reboot and is still exposed.\u003C\u002Fp>\u003Cp>Do not lean on the version number alone. Distributions routinely backport fixes into their own kernel builds without matching the upstream version, as \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F10\u002Fcritical-pwnescape-linux-kernel.html?ref=ghost.jdneer.com\">The Hacker News\u003C\u002Fa> also points out. Check your distribution's security tracker or changelog for CVE-2026-99999, or for the \"validate checksum_start\" change, and confirm that the specific build you are running includes it. On Proxmox VE 9, that means confirming each node is booted into 7.0.14-24-pve or newer.\u003C\u002Fp>\u003Cp>While you wait for a maintenance window, reduce what a successful escape could reach. Vercel says it keeps host kernels current, disables nested virtualization, and runs each microVM under Firecracker's jailer, which limits the VMM process to only the permissions it needs. None of that fixes PwnEscape, but it narrows the damage if someone gets there first.\u003C\u002Fp>\u003Cp>PwnEscape is also a reminder of how quickly bug hunting is changing. pwn.ai says it found the flaw in about three days with an AI-assisted system, at a cost of under $700 in API usage, according to \u003Ca href=\"https:\u002F\u002Fthehackernews.com\u002F2026\u002F10\u002Fcritical-pwnescape-linux-kernel.html?ref=ghost.jdneer.com\">The Hacker News\u003C\u002Fa>. If finding kernel bugs keeps getting faster and cheaper, the time between a fix landing and someone weaponizing it will keep shrinking too. For anyone running shared virtualization, the safest assumption is simple: patch the host, reboot the host, and do not let the reboot wait.\u003C\u002Fp>","PwnEscape (CVE-2026-99999) is a critical bug in the Linux host's IPv4 stack, not KVM, that lets a guest VM read host memory, crash the host and, in the...",{"src":60,"width":73,"height":74,"type":75},1600,900,"image\u002Fpng",{"name":77,"url":78,"owner":13},"Aiko Tanaka",null,[80,90,101,112],{"slug":81,"title":82,"excerpt":83,"image":84,"publishedAt":85,"topics":86,"readMinutes":89},"http2shell-cve-2026-111497-brotli-decoder","HTTP2Shell (CVE-2026-111497): What the Brotli Decoder Bug Really Hits, and How to Patch","CVE-2026-111497 is an out-of-bounds write in Google's Brotli decoder, 1.0.3 through 1.2.0. Fixed in 1.0.10, 1.1.1 and 1.2.1, plus Node.js, Bun, Python, Envoy and .NET updates. You are exposed if you decode untrusted Brotli data. Not in CISA KEV.","\u002Fcontent\u002Fimages\u002F2026\u002F10\u002Fhttp2shell_cve_2026_111497_v2.png","2026-10-26T20:51:27.000+08:00",[87,88],{"key":64,"label":65},{"key":67,"label":68},1,{"slug":91,"title":92,"excerpt":93,"image":94,"publishedAt":95,"topics":96,"readMinutes":89},"package-cooldowns-github-package-firewall-npm-pnpm-bun-pip-uv-poetry","Package Cooldowns Compared: GitHub Package Firewall vs. What npm, pnpm, Yarn, Bun, pip, uv and Poetry Already Do","GitHub now offers an install-time firewall for npm, free in preview and metered later. Most package managers already ship a free cooldown. Here is what each tool does, the copy-paste config, and where cooldowns stop helping.","\u002Fcontent\u002Fimages\u002F2026\u002F10\u002Fpkg-cooldowns-conveyor-alberto-rodriguez-unsplash.jpg","2026-10-26T14:00:00.000+08:00",[97,100],{"key":98,"label":99},"guides","Guides",{"key":67,"label":68},{"slug":102,"title":103,"excerpt":104,"image":105,"publishedAt":106,"topics":107,"readMinutes":89},"tailscale-ssh-tailworm-mesh-vpn-agent-risk","Your Mesh VPN Agent Is Root on Every Box. Tailworm Is the Reminder.","A researcher showed one hacked Tailscale node reaching root on other servers through Tailscale SSH forwarding. No patch yet. Here is why mesh VPN agents deserve the same suspicion as any privileged daemon.","\u002Fcontent\u002Fimages\u002F2026\u002F10\u002Ftailworm-padlock-light-trails-flyd-unsplash.jpg","2026-10-26T12:00:00.000+08:00",[108,111],{"key":109,"label":110},"opinion","Opinion",{"key":67,"label":68},{"slug":113,"title":114,"excerpt":115,"image":116,"publishedAt":117,"topics":118,"readMinutes":89},"emudhra-ca-weak-keys-chain-of-trust","eMudhra Broke Almost Nothing, and Still Dented the Chain of Trust","Eight eMudhra intermediate CA keys turned out to be numbers under 256. Browsers blocked them within hours, almost no site broke, and eMudhra is leaving the TLS business. The service impact was tiny. The lesson for the chain of trust is not.","\u002Fcontent\u002Fimages\u002F2026\u002F10\u002Femudhra-keys-iolandino-baiano-unsplash.jpg","2026-10-25T16:00:00.000+08:00",[119,120],{"key":109,"label":110},{"key":67,"label":68},{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":122},"\u003Cpath fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M5 12h14M5 12l6 6m-6-6l6-6\"\u002F>",{"left":15,"top":15,"width":26,"height":26,"rotate":15,"vFlip":13,"hFlip":13,"body":124},"\u003Cg fill=\"none\" stroke=\"currentColor\" stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\">\u003Cpath d=\"M6.5 7.5a1 1 0 1 0 2 0a1 1 0 1 0-2 0\"\u002F>\u003Cpath d=\"M3 6v5.172a2 2 0 0 0 .586 1.414l7.71 7.71a2.41 2.41 0 0 0 3.408 0l5.592-5.592a2.41 2.41 0 0 0 0-3.408l-7.71-7.71A2 2 0 0 0 11.172 3H6a3 3 0 0 0-3 3\"\u002F>\u003C\u002Fg>"]