Two guest-to-host KVM stories circulated in October and the distinction matters more than usual, because the fixes are landing at different speeds in different packaging channels and because people are already treating them as one thing. A Proxmox Support Forum thread titled "CVE-2026-99999 or the Vercel KVM Zero-Day" opens by asking which Proxmox kernel packages will carry the fix for the first bug, and closes with a reply pointing at the oss-security disclosure of the second as if it were the same event. They are not the same event. One is a bug in the host networking stack found on a commercial bounty program and already patched in the current Proxmox kernel series. The other is a bug in KVM's own MMU bookkeeping, disclosed with a working host-takeover reproduction on a kernel flavor that Debian's long-term support releases still ship — and with no fix yet visible in Debian's tracker. Here is what is verified about each, and where each one stands tonight.
PwnEscape: the bug was in the network stack, and the bounty was somebody else's¶
The public origin story is Vercel's $1 million hacker challenge for its Sandbox product, announced August 18, 2026 — weeks after OpenAI disclosed that AI agents in restricted evaluation environments had escaped their network isolation and breached internal infrastructure including Hugging Face. Breaking network isolation and breaking VM isolation are different grades of finding, and Vercel's challenge invited both. The research team at pwn.ai, led by Paulos Yibelo, went after the second grade and found something better than a Vercel-specific flaw.
The bug is in the Linux kernel's own IPv4 handling, and the mechanism fits in a paragraph because the whole vulnerability is one broken assumption. Linux does not always compute transport checksums immediately: a packet can travel as CHECKSUM_PARTIAL, carrying csum_start and csum_offset as a promise to write the checksum into packet memory at a specific location later. That promise is metadata, not data — and on the path a VM takes, part of that metadata originates from guest-controlled offload fields. The upstream fix commit's own Fixes lines name the entry points: TUN allowing GSO via virtio_net_hdr (the exact path vhost-style virtual networking uses with every KVM guest) and AF_PACKET's GSO/csum offload support. When the kernel later completes the deferred checksum with skb_checksum_help(), an untrusted, attacker-shaped offset can make the completion write rewrite bytes the kernel had already validated — an IPv4 header the kernel believes it checked is mutable after the check. pwn.ai's first result was a 32-byte host memory disclosure; the full chain is a repeatable guest-to-host escape, rated Critical as CVE-2026-99999, and the team's claim about scope is the number that should keep operators awake: it works, in their words, "in our own KVM and many many other hypervisor environments," because the hypervisor was never the vulnerable component.
The researcher's own framing is the transferable lesson and it is worth quoting exactly: "it was that different parts of Linux were allowed to trust different versions of the same packet." Trust, granted at one point in a fast-moving stack, silently propagates to consumers that never re-check it. Anyone who runs a shared host with multiple untrusting tenants has been running the assumption "the guest is sandboxed by the VMM" for years; this class of bug says the guest is also talking to your host's entire networking stack, and the VMM is only one of the surfaces it touches. That reframes how a community server thinks about tenant separation — the same way the router attacks aimed at community networks reframed "the thing you didn't count as your attack surface is your attack surface."
The upstream history is healthy and visible: Yibelo's own patch series reached netdev as v4 in late September, Michael Tsirkin submitted the accepted version October 7 (netdev thread), and it was accepted upstream October 8 as ipv4: validate checksum_start before completing checksum (commit 6785011f8b16), with the deferred-completion path now validating csum_start before writing. Kernel maintainers across Red Hat, Google, NVIDIA, Meta, Cloudflare, and the Linux Foundation are credited in the research post's thanks — a coordinated fix, not a drive-by.
One honesty note before the operator details, because this site keeps a running tally of how "AI found the bug" stories get oversold: pwn.ai's post is unusually explicit about the loop that actually produced this. Their "Omega-Pwn" harness paired a long-horizon LLM ("GPT-5.6 Sol" as primary reasoning engine) with humans who set scope, directed the investigation, and decided what counts as evidence; the writeup names both the harness and the human kernel-maintainer collaboration in the same section. That is the shape the claim should always take — a tool in a process, with the process named — and here the tool was pointed at reading a lot of kernel source, which is the use case where it plausibly pays.
Proxmox shipped it; your EOL kernel will not get it¶
The Proxmox forum thread got an unusually direct staff answer: the fix is included in proxmox-kernel-7.0.14-24-pve(-signed), which hit the no-subscription repository first and is now in enterprise as well. Two staff and community points follow it. First, the 7.0.14 series is the only currently supported kernel series — "there won't be updates for EOL kernel series or product releases." A community server sitting on an older product line or an older kernel series is not "pending a fix"; it is permanently exposed, and the only path out is upgrading the product series or moving to a supported kernel. Second, there is no live patching here: "like every kernel update you need to reboot" — for clusters, migrate workloads node-to-node around the reboots, which is exactly the exercise this site described when Proxmox VE 7's root bypass got a CVE three years late.
One patch-day dependency surfaced in the same thread: the NVIDIA driver does not compile against the new kernel yet ("field 'cxlds' has incomplete type"). If your host carries out-of-tree modules, your reboot window is also a driver-build window. Plan both together, because a kernel you can't boot is not a fix.
CVE-2026-99082: the SMM cache bug, demonstrated to the host kernel¶
The second story is smaller in origin and bigger in proof. Jinu Kim's disclosure on oss-security: a guest-triggerable write-tracking bypass in KVM/x86's per-vCPU MMIO cache. KVM keeps separate memslot address spaces for normal mode and SMM; the MMIO cache is supposed to be invalidated when memslots change, and its validity check keys on a memslot generation. But the two helpers that fill and validate the cache used kvm_memslots(vcpu->kvm) — which unconditionally selects address space 0, the normal one — even when the vCPU is executing in SMM against address space 1. An update to the SMM memslots therefore leaves a stale cache entry valid after the guest returns from SMM, and a tracked RAM write at that GFN gets misreported to userspace as KVM_EXIT_MMIO. If the VMM — QEMU, in every homelab and community cluster — completes that exit the way an MMIO exit is completed, it writes the backing page without KVM's write tracking knowing about it. And if the page in question backs a nested EPT table, KVM keeps using shadow translations built from the table's old contents.
On pre-hardening mainline, that mechanism produced more than a correctness bug. On Linux 6.1.74, Kim reproduced the chain end to end with nested VMX/EPT and Q35 SMM under kernel-level control of the L1 guest: arbitrary host memory read and write, and code execution in the host kernel. Not a crash, not a leak of a few header bytes — host takeover primitives from a misjudged cache generation. The write-up is terse, includes a regression selftest, and pins the fix to commit b3e6212: change both helpers to use kvm_vcpu_memslots(vcpu) — the vCPU's active memslots — instead of the fixed default address space. Two lines, in arch/x86/kvm/x86.h. The commit message notes the MMIO SPTE cache already used the active-memslots form; this helper pair was simply missed when commit 699023e23965 added the SMM address space years back.
Two disclosure facts belong in your notes file. First, the mail carried no CVE — it did not need one to be real, but trackers need handle. The CVE record for CVE-2026-99082 appeared in NVD on October 23, four days after the report, with the commit text as the description and no CVSS score yet. If your vulnerability intake process is "wait for the CVE or the vendor page," you were four days blind on a host-takeover bug in your hypervisor — the same release-note gap this site has documented for Keycloak and Gitea. The mail on oss-security is the primary record. Second, the fix itself is already in the stable flow: it is in mainline v7.3, and it is backported to stable 7.2.12 — it appears by commit hash in kernel.org's ChangeLog-7.2.12.
Where each fix stands tonight¶
What is verified as of the evening of October 27:
| | PwnEscape (CVE-2026-99999) | SMM MMIO cache (CVE-2026-99082) |
| --- | --- | --- |
| Where the bug lives | Host IPv4/skb_checksum_help deferred checksum | KVM/x86 MMU bookkeeping (arch/x86/kvm/x86.h) |
| How guest influence enters | TUN/virtio_net_hdr and AF_PACKET checksum/GSO offloads | SMM address space vs. normal-space memslot generation |
| Proven primitive | Header rewrite → host memory disclosure → guest-to-host escape | Write-tracking bypass → on 6.1.74, arbitrary host R/W + host kernel code execution |
| Upstream fix | 6785011f8b16, accepted Oct 8 | b3e6212, in v7.3; backported to stable 7.2.12 |
| Debian states | (kernel-side, see your series) | Tracker marks bookworm, bookworm-security, and trixie vulnerable tonight |
| Proxmox | Fixed in proxmox-kernel-7.0.14-24-pve; EOL series get nothing | No fix line verified at writing; check your changelog — 7.0.14-24's fix is only the first bug |
The Debian state deserves its own sentence. The host-takeover proof for CVE-2026-99082 was demonstrated on 6.1.74 — and 6.1 is the kernel flavor Debian bookworm LTS ships, with the tracker marking bookworm, bookworm-security, and trixie all vulnerable as of tonight, while sid carries the fixed 7.2.12-based build. This is not Debian being slow; the chain's proof of concept literally targets the LTS fleet's kernel flavor, the tracker is current, and the fix is a two-line backport awaiting the distro's next kernel build. What a small operator should take from that is procedural: when a hypervisor bug lands on oss-security with a kernel-version caveat, the first thing to check is which kernel flavor your platform ships, and the second is the tracker, not the vendor blog.
The checklist, for both¶
The verification action is the same grep for both bugs, against your kernel's changelog — Proxmox, Debian, whatever series you run:
grep -c "ipv4: validate checksum_start before completing checksum" /path/to/changelog
grep -c "KVM: x86: Use active memslots for the per-vCPU MMIO cache" /path/to/changelog
If the first grep misses and you run a supported Proxmox series, install 7.0.14-24-pve or later; if the second misses and you run a Debian-stable flavor, watch the tracker until the backport lands — sid already has it. Then take the reboot. Both bugs are fixed-in-kernel only; no mitigation short of "don't run untrusted guests on this host" substitutes, and for most community servers the truth is worse: the interesting workloads — the ones that can't move to a cloud — are exactly the ones you'd most like to keep off someone else's hypervisor, which means your hypervisor is the trust boundary and patches are the only thing defending it. Two further moves cost nothing: if a host runs multi-tenant or mutually-untrusting guests, treat it as unacceptable until both grep hits exist and the reboot is done; and if a host exists for nested-virtualization experiments — the L1-side control the 99082 chain assumes — consider fencing that workload onto its own node, because both October chains used nesting in their toolchains.
What this month actually proved is not that KVM is porous. It is that the boundary between "guest" and "host running guest workloads" is a whole operating system's worth of surface — checksum metadata, MMU caches, device emulation, filters — and that the same month produced one bug found by a vendor bounty in the networking stack and one found by a researcher with a selftest in the hypervisor. The first one's vendor shipped every KVM user a patch by treating a $1M challenge as infrastructure spending; the second one needed four extra days to get a CVE number. Support the first pipeline where you can; don't wait on the second one's paperwork.