Zapscape and SCTPhantom: your Proxmox does not run Debian's kernel

Two named Linux kernel flaws were published this week. Zapscape lets you break out of a KVM virtual machine and walk away with the host. SCTPhantom turns an unprivileged user into root and takes the container boundary with it. Understanding them takes twenty minutes. The question that actually occupied our morning was a different one: does the kernel our nodes boot already carry the fixes? Neither advisory answers that.

We are writing this from the side that has to apply it. We run Proxmox VE with Ceph storage in production, spread across several datacentres, so the advisory was not reading material: it was a list of nodes to reboot. And when we went to check the obvious, we hit the gap this article is about — which is not technical but procedural, and which repeats itself in plenty of places beyond Proxmox.

Zapscape: getting out of the virtual machine

CVE-2026-64561 is a use-after-free in KVM's x86 shadow MMU emulation, specifically in the recursive zap path that runs when KVM reclaims shadow pages. The patch message puts it plainly: the check for an invalid or obsolete root has to happen after making pages available, not before, because "if reclaiming shadow pages zaps an in-use root, KVM will attempt to map memory into an invalid root", and child pages inherit their parent's role, so they are created invalid and end up on the list of active pages — precisely the invariant KVM promised never to break. The fix moves the check behind make_mmu_pages_available().

What it takes to get there matters a great deal, and it is worth stating before the impact: kernel privilege inside the L1 guest — in practice, root in the virtual machine — and nested virtualisation, because that is what forces KVM onto the shadow MMU instead of hardware-assisted paging. On Intel you additionally need both four- and five-level EPT page walks exposed to that guest; on AMD there is no equivalent condition. Researcher Hyunwoo Kim, credited with the find, published a working proof of concept against AMD demonstrating the full chain on QEMU in TCG mode across three stacked layers (L0, L1 and L2). Red Hat has assigned it a preliminary 7.0.

There is a second path that gets mentioned less and that on some servers is the one that really stings: where /dev/kvm is accessible to ordinary users, you do not need to be anybody's tenant. Anyone with an account can spin up a throwaway virtual machine and attack the host from inside it. The flaw lives in the kernel's KVM, so whichever QEMU version you run is irrelevant.

SCTPhantom: eighteen years waiting

CVE-2026-64564 sits in SCTP's dynamic address reconfiguration, the ASCONF mechanism that lets an association add, remove or move network paths on the fly. The kernel validates an address deletion using the packet's source address, but separately keeps a cached pointer to the transport selected by the message's own address parameter. Those two identities need not match. A single ASCONF carrying, in order, [parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] passes the existing check, frees the transport the cached pointer still refers to, and then reuses it: the association ends up with zero transports and its primary path pointing at freed memory.

It is credited to Tencent's Zhuque Lab, which rates it 8.5 on CVSS 4.0 with a local vector (AV:L/PR:L) and reports getting root on the kernels it tested from Debian 13, Ubuntu 24.04, OpenCloudOS, and Rocky Linux 9 and RHEL 9 — the last two with the SCTP module loaded by hand. The part that interested us most is the container escape: the chain reaches code execution in the host's initial namespaces without needing CAP_NET_ADMIN or CAP_SYS_ADMIN, succeeding six times out of eight. And the faulty code goes back to Linux 2.6.25, December 2007. Eighteen years.

The age impresses, and it deserves some deflating, because it does not measure risk. Zapscape's own patch carries a note that explains this better than we could: the underlying defect had existed since KVM started tracking invalid roots in 2008, but "the true badness" only arrived in 2020, with Linux 5.9, when the invariant that now breaks was introduced. Put differently: a flaw can sit in the code for years without being exploitable, and become exploitable the day somebody adds, in perfectly good faith, an optimisation around it. Eighteen years in the tree does not mean eighteen years of anybody exploiting it.

The awkward question: am I patched?

The fixed versions quoted in every piece of coverage are these: 6.6.148, 6.12.101, 6.18.42, 7.1.6 and the development 7.2-rc5. Now run uname -r on a Proxmox VE node. It will answer something like 6.8.12-x-pve, 6.14.11-x-pve, 6.17.13-x-pve or 7.0.14-x-pve. None of those branches appears in the list. That is neither good news nor bad: they are simply not the same branches.

Debian published advisory DSA-6415-1, which closes both flaws on trixie with the linux package at 6.12.101-1. Excellent, except for one detail: that is not the kernel your node boots. Proxmox VE is Debian, but its kernel does not come from Debian, it comes from Ubuntu. Its own documentation says so: Proxmox VE 9.0 was based on 6.14 derived from Ubuntu 25.04, Proxmox VE 9.1 moved to 6.17 derived from Ubuntu 25.10, and Proxmox VE 9.2, released on 21 May 2026, made kernel 7.0 the new default — also Ubuntu-derived. You can have Debian's linux package perfectly up to date on the machine and never boot it.

It holds for any system with a vendor kernel — a storage array, a NAS: the CVE record and your distribution's advisory tell you the flaw exists, not whether the binary you boot carries the fix.

The answer, with numbers: -9 is not enough

The answer lives in the pve-kernel repository, not in any bulletin. On the 7.0 branch, the one Proxmox VE 9.2 ships, the history is explicit:

• 7.0.14-9 — "cherry-pick fix for CVE-2026-64561". Zapscape lands here, alongside fixes for CVE-2026-64562 and CVE-2026-64047 and others the commit groups as "further CVEs".
• 7.0.14-10 — "backport sctp: don't free the ASCONF's own transport…". That is SCTPhantom, and it arrives in the next bump.
• 7.0.14-11 — an additional x86/bugs backport ("Make Safe-RET robust against interrupts"). It is the latest published as we write: if you are going to reboot, reboot into this one.

Which yields the practical takeaway of the whole article: if you stopped at 7.0.14-9 you have Zapscape fixed and SCTPhantom not. Two named flaws, two consecutive bumps, and a one-digit difference that appears in no news story. Whoever rebooted the moment they saw the first has earned themselves a second reboot; whoever waited a day saved a window. It is also worth checking which repository you eat from: -9 appeared first on pve-test and only the next day on pve-no-subscription, and the subscription one usually trails behind.

And if you are not on 7.0? This is where this article would have stopped halfway, because the same git answers for the other branches. On Proxmox VE 8.x, Proxmox staff state on their forum that Zapscape is covered in proxmox-kernel-6.8.12-40-pve — and watch out, because the exact same pattern repeats there: the SCTP backport lands in the next bump, 6.8.12-41, together with the same x86/bugs fix. -40 gives you Zapscape; SCTPhantom starts at -41. And on the 6.17 (Proxmox VE 9.1) and 6.14 (Proxmox VE 9.0) branches the git speaks by omission: neither records a single commit related to these two flaws, and their last movement dates from 20 July and 15 May respectively. If that is where you are, you do not have it yet.

How to check on your node

Four commands. The first two say what is running; the last two, what you have in place:

uname -r                              # what is running NOW, in memory
pveversion -v | grep -i kernel        # Proxmox version and running kernel
apt list --installed 'proxmox-kernel-*'   # what is INSTALLED on disk
proxmox-boot-tool kernel list         # kernels synced to the ESP (if you use proxmox-boot-tool)

The fourth only applies if boot is managed by proxmox-boot-tool — installations on ZFS or using systemd-boot; on a classic GRUB install it will not help you. And it lists the kernels synced to the ESP, not which one wins the boot: that is pinned with proxmox-boot-tool kernel pin.

An installed kernel is not a booted kernel. We wrote a few days ago about Chrome's patching cadence and the gap between downloading an update and restarting the browser; this is the same thing without room for interpretation, because a kernel only takes effect on reboot. There is no live patching to lean on in a standard Proxmox deployment.

In a cluster, the reboot is the real work. Our order is always the same: live-migrate the node's workloads, drain it, and only then reboot. If Ceph sits underneath, setting noout before touching anything stops the cluster rebalancing terabytes because a node has been away for four minutes. And after boot, confirm uname -r says what you expected before moving to the next node. The rest of the criteria we use to leave a cluster in shape are in the hardening checklist we published.

Who needs to hurry and who does not

This is where we part company with the tone of the coverage. Zapscape requires somebody to hold kernel privilege inside a guest and that guest to have nested virtualisation available. If every virtual machine in your cluster is yours or your client's, if nobody outside has root inside them, and if you do not expose nesting, this is an ordinary patch window, not a Saturday emergency. Saying the opposite sells more articles, but it wears down the credibility of whoever later warns about something genuinely urgent.

Now, if you sell VPS hosting, if you hand virtual machines to third parties with root inside, if you keep nesting switched on for labs or training, or if /dev/kvm is open to ordinary users on a shared machine: then yes, patch this now. The difference between the two scenarios is not the flaw, it is who holds root inside your guests — a design question, not a reactive-security one.

SCTPhantom has a similar and less publicised constraint: SCTP has to be reachable. On the oss-security list, Solar Designer pointed out that on the RHEL family the module ships in kernel-modules-extra with blacklist sctp and blacklist sctp_diag, so an administrator has to install and load it deliberately to be exposed. On Debian and Ubuntu, by contrast, Tencent got root on the installations it tested. Checking costs a second: lsmod | grep sctp.

Management boundaries, not walls

What strikes us most about the pair is not either flaw on its own, but what they say together. One breaks the virtual machine, the other breaks the container, and both surface the same week in the same kernel. Those are the two boundaries we rest almost everything on, and both are, at bottom, C code somebody wrote years ago.

The conclusion we draw is not to stop trusting virtualisation — that would be absurd, we operate it every day — but to treat it as what it is: an excellent management boundary and a reasonable but not absolute security boundary. That changes concrete decisions: do not mix workloads with very different trust levels on the same host, do not leave nesting enabled "just in case", and do not treat "it is in another VM" as equivalent to "it is on another machine". The same logic we apply when deciding when a cluster has to be split in two: what really separates is the boundary you chose, not the one you assumed.

What we would not do

• Reboot the whole cluster at once. Node by node, migrating and verifying. A local flaw that requires already being inside does not justify losing quorum mid-afternoon.
• Assume the node is patched because the distribution advisory came out. That is the specific error behind this article. Check the version of the kernel you boot, not of the package that exists.
• Blacklist SCTP blindly. For most servers it is sensible hygiene, but if you operate telecoms signalling the protocol is genuinely in use. Look at lsmod before writing a blacklist entry.
• Treat "not being exploited" as an open-ended permission. There is a public proof of concept for Zapscape. Its author warns it is not a ready-to-run exploit — the L1 actions have to be moved into a guest kernel module and ported to the host's kconfig — but adds in the same breath that this is not a difficult task. That shortens the window even if there are no campaigns today.

The boring part of this is what actually decides the outcome: knowing which kernel each machine boots, having a window in which to reboot without asking anyone's permission, and having somebody read the vendor's history when the generic bulletin does not reach that far. It is exactly the job of maintaining a managed estate, and nobody notices it until the week that needs two reboots in a row over a one-digit difference. If you would like us to review the state of your virtualisation, get in touch.