CVE-2026-53359: Patch This KVM Flaw on Proxmox VE

CVE-2026-53359 is a use-after-free in KVM's x86 shadow MMU, and because Proxmox VE is itself a KVM host, your hypervisor is the affected component — not a guest workload. The concrete fix is to pull the latest Proxmox kernel with apt full-upgrade, reboot, and confirm uname -r sits at or above the fixed upstream stable base for your branch. Until you can reboot, disabling nested virtualization shrinks the shadow-paging attack surface that this bug lives in.

Key Takeaways

• Host bug: CVE-2026-53359 lives in the KVM hypervisor on your Proxmox node, so a guest action can corrupt host kernel memory.
• No CVSS yet: NVD has assigned no v3/v2 score and EPSS is ~0.18% — worth patching, but not a known in-the-wild exploit.
• Nested is the path: On modern EPT/NPT hardware, shadow paging is mainly exercised by nested guests (an L2 VM inside an L1 VM).
• Real fix: apt update && apt full-upgrade, then reboot — a patched-but-not-rebooted host is still vulnerable.
• Stopgap: Disable nested virtualization (nested=0) before you can reboot, accepting that it breaks nested hypervisors.

What is CVE-2026-53359, and why does it matter on Proxmox?

CVE-2026-53359 is a Linux kernel vulnerability published on 2026-07-04 and last modified 2026-07-08, currently in the PUBLISHED state. It is a use-after-free in KVM's x86 shadow paging — the software page-table path, also called the shadow MMU.

The mechanics are specific. It follows the earlier kernel commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN"), which closed one instance of the problem while a similar hole remained. The bug triggers when a PDE mapping is changed from outside the guest and a memory slot (memslot) is then deleted. In that window, rmap_remove() misses SPTEs created after the PDE change, because the leaf SPTE's GFN no longer matches the GFN recorded on the owning struct kvm_mmu_page. The result is a dangling shadow page — a use-after-free in host kernel memory.

Translate that to operations: a guest can drive host-kernel memory corruption. That is a hypervisor-boundary memory-safety bug, with realistic worst cases of a host denial of service or a privilege-boundary violation. This is exactly the class of exposure covered in LOLPROX: Protecting Proxmox from Hypervisor Exploits, and it is why "it's only a guest" is not a safe framing on a KVM host.

How bad is it, honestly?

Do not let the scary "use-after-free in the hypervisor" phrasing push you into panic-patching outside a change window. As of this writing:

• NVD has assigned no CVSS score — both v3 and v2 are null.
• EPSS is roughly 0.18% (percentile ~7%), which is low real-world exploitation probability.
• It is not in CISA KEV, has no known ransomware association, and there are 0 Metasploit modules.

So the honest read is: a genuine hypervisor-boundary memory-safety flaw that deserves a patch on its normal cadence, not a fire drill. Treat it as "schedule the reboot this maintenance window," not "call everyone in at 2 a.m."

Is my Proxmox host actually exposed?

Shadow paging is the fallback KVM uses when hardware-assisted paging — Intel EPT or AMD NPT, collectively TDP (two-dimensional paging) — is unavailable or disabled. On any modern Proxmox host, TDP is active for normal L1 guests, so those guests do not exercise the shadow MMU path in the same way.

The realistic exposure on a typical modern node is nested virtualization: an L2 guest running inside an L1 guest. Nested guests are where shadow paging still gets heavily used, which makes them the practical trigger surface for this bug. If you run nested hypervisors for testing — the pattern in Proxmox VE Nested Virtualization for Homelab Testing — you are the primary audience here.

First, confirm whether nested virtualization is even enabled on the host:

# Intel hosts
cat /sys/module/kvm_intel/parameters/nested
# AMD hosts
cat /sys/module/kvm_amd/parameters/nested

A Y (or 1) means nested is on and the shadow-paging path is reachable via nested guests. An N (or 0) means the most relevant exposure path is already closed.

Audit which guests actually nest

Enabling nested at the module level is necessary but not sufficient — a VM only nests if its CPU exposes virtualization extensions. Check each VM's config for cpu: host or an args: line that force-adds +vmx (Intel) or +svm (AMD):

# Inspect a single VM
qm config 105 | grep -E 'cpu|args'

# Sweep every VM on the node for nesting hints
for vmid in $(qm list | awk 'NR>1{print $1}'); do
  echo "== VM $vmid =="
  qm config "$vmid" | grep -E 'cpu:|args:.*(vmx|svm)'
done

On a 40-VM node this sweep finishes in well under two seconds, and it will usually show that only a handful of VMs (your lab or CI hypervisors) actually carry cpu: host. Those are the machines that matter for this CVE.

Gotcha from the field: a guest set to cpu: host picks up +vmx/+svm implicitly even without an explicit args: line, so grepping only for vmx/svm will miss it. Always include cpu: in the audit, or you will convince yourself a nesting-capable VM is safe when it is not.

The real fix: update the Proxmox kernel and reboot

The only thing that actually closes CVE-2026-53359 is a fixed kernel. The fix is present upstream in stable kernels 6.1.177, 6.6.144, 6.12.95, 6.18.38, and 7.1.3 (7.2-rc1), and Proxmox ships it through its normal kernel updates.

Pull and install:

apt update && apt full-upgrade

Then reboot — this is the step people skip, and it is the one that matters:

systemctl reboot

A host that is patched-but-not-rebooted is still running the vulnerable kernel in memory. apt staged the new kernel on disk; the running vCPUs are still the old, buggy code until the box comes back up.

After the reboot, verify you are on a fixed kernel and confirm the Proxmox package set:

uname -r
pveversion

Check that uname -r reports a kernel at or above the fixed upstream stable base for your branch. If you are on a 6.12 branch, that means >= 6.12.95; on a 6.8 branch, confirm the fix has been backported into the Proxmox build you are running rather than assuming the raw upstream number applies. When in doubt, cross-reference the full CVE-2026-53359 technical breakdown and references, which aggregates the upstream fix commits, NVD data, and public-PoC tracking (four public PoC references are listed there) in one place.

Reboot the guests too

After the host is patched and rebooted, reboot your guests as well — especially nesting-capable ones. A VM that keeps running keeps a live pre-patch vCPU context on the (now-updated) host, and you want no VM holding a stale, pre-patch vCPU state:

qm reboot 105

For a graceful, staggered restart of every running VM:

for vmid in $(qm list | awk '$3=="running"{print $1}'); do
  qm reboot "$vmid"
  sleep 5
done

How do I mitigate before I can reboot?

If your change window is days out, shrink the shadow-paging attack surface now by disabling nested virtualization. This is a stopgap, not a fix — it makes the primary trigger path unreachable while you wait to reboot.

Create a modprobe drop-in. On Intel:

# /etc/modprobe.d/kvm-nested.conf
options kvm-intel nested=0

On AMD:

# /etc/modprobe.d/kvm-nested.conf
options kvm-amd nested=0

Apply it by reloading the KVM module (no running nested guests must hold it):

modprobe -r kvm_intel && modprobe kvm_intel
# AMD:
# modprobe -r kvm_amd && modprobe kvm_amd

If the module is in use and will not unload, the drop-in still takes effect on the next reboot — which you are doing anyway for the real fix. Verify the parameter now reads disabled:

cat /sys/module/kvm_intel/parameters/nested   # expect: N

The honest tradeoff

Disabling nested virtualization will break every workload that depends on it: nested ESXi or Hyper-V labs, Windows guests using WSL2 or VBS (Virtualization-Based Security), and Docker-Desktop-style nested KVM. If those are production for you, weigh the stopgap against the low EPSS score — you may reasonably decide to skip the stopgap and go straight to a well-scheduled kernel reboot instead.

Which action closes what?

Here is how the three moves compare, so you can sequence them correctly:

Action	Closes the CVE?	Downtime	Breaks nested workloads?
apt full-upgrade only (no reboot)	No — vulnerable kernel still running	None	No
apt full-upgrade + host reboot	Yes — this is the real fix	~2–5 min per node	No
nested=0 stopgap	No — reduces attack surface only	Module reload or reboot	Yes
Reboot guests after host patch	Clears stale pre-patch vCPUs	Per-VM restart	No

The takeaway from the table: only the second row actually fixes CVE-2026-53359. The stopgap and the guest reboots are supporting moves around it.

Where this sits in your broader Proxmox hardening

This CVE is a reminder that the hypervisor boundary is a real trust boundary, not a formality. The same discipline applies to container escapes like Leaky Vessels (CVE-2024-21626): Container Escape Risk for Docker on Proxmox — a guest- or container-side action reaching host memory or the host filesystem.

Patching kernels is one layer; controlling who can reach the host in the first place is another. If you have not already tightened the management plane, pair this update with the steps in Hardening Proxmox VE: Firewall, fail2ban, and SSH Security so that even a memory-safety bug has fewer ways to be reached.

A practical cadence that will keep you ahead of this class of bug:

1. Subscribe to the Proxmox VE and pve-devel announcement channels so kernel CVEs land in your inbox, not your logs.
2. Keep a monthly reboot window per node — memory-resident kernel fixes are worthless until you cycle the box.
3. Track nesting-capable VMs in an inventory so you know your true exposure surface for any future KVM CVE in seconds.

Conclusion

CVE-2026-53359 is a legitimate use-after-free in KVM's shadow MMU that a guest can use to corrupt host kernel memory — real, but with no CVSS score, ~0.18% EPSS, and no known exploitation, it is a scheduled-patch job rather than an emergency. The decisive action is to run apt full-upgrade, reboot onto a fixed kernel (for example >= 6.12.95 on a 6.12 branch), confirm with uname -r, and reboot your guests. Your next step: audit which VMs carry cpu: host, apply the nested=0 stopgap if your reboot window is not immediate, and book that kernel reboot.