Patching PwnEscape on Proxmox VE: kernels, reboots and rolling upgrades

Proxmox fixed PwnEscape (CVE-2026-99999) in proxmox-kernel-7.0.14-24-pve, the only kernel series it still supports. Every Proxmox VE host that runs guests needs that build or later, installed with apt full-upgrade and actually booted. Older series, including everything on Proxmox VE 8, get no fix. Check each node with uname -r after the reboot.

This is the Proxmox companion to our PwnEscape explainer, which covers the bug, the disputed scores and other distributions. Here we stay on one platform: what Proxmox shipped, which kernels are covered, how to patch one box, how to roll a cluster without dropping guests, and what to do on an end of life series.

What Proxmox shipped, and when

Proxmox published security advisory PSA-2026-00068-1, titled "PwnEscape" Guest-to-Host KVM Escape, on 16 October 2026. It names one package, proxmox-kernel, and one fixed build: proxmox-kernel-7.0.14-24-pve and its signed variant. It describes incomplete validation of packet checksum metadata in the virtio network stack, letting a guest read host memory and write host kernel memory, and lists no mitigation.

The changelog for build 24 does not name the CVE. Proxmox staff member Fabian explained on the forum that it predates the CVE assignment, that an earlier variant of the fix first appeared in build 22, and that build 24 swapped in the final version.

Two details matter. If you installed build 22 or 23 in early October, you have the earlier variant, not the final fix. And build 25, dated 17 October, fixes further KVM issues on AMD hosts with nested virtualization. One forum user claims build 25 is also needed for PwnEscape; staff have not said so and the advisory still names build 24. Taking the newest build covers both readings.

How urgent is it?

pwn.ai showed a full guest to host chain only on its own lab hosts, but forecasts exploits for default hypervisor configurations "in under a month." Our explainer found no confirmed in-the-wild exploitation as of 21 October. Proxmox guests talk to the host through virtio-net, the path the advisory names, so nodes running guests you do not fully control go first.

Which kernel series are covered

On 16 October Fabian wrote that "the 7.0.14 series is the only currently supported kernel series," and that end of life series get no updates. On 19 October, asked about 5.4, 5.15 and two 6.8 builds, he confirmed those series and their product releases are all end of life. Mapped onto releases, using the Proxmox roadmap and FAQ:

Proxmox has not published a per-series list; the 6.17 and 6.14 rows are our reading of the staff statement. Proxmox's April announcement of the opt-in 7.0 kernel also said 7.0 would not be offered for Proxmox VE 8, so an 8.x host needs an upgrade to 9 before it can run the fix.

Check what each node is running

You need two facts per node: which kernel is installed and which is running. They often differ.

1. The running kernel. This is the only one that counts.

uname -r
# expected after patching: 7.0.14-24-pve or a later build

2. The Proxmox view of the same thing. The first line of pveversion -v includes the running kernel, and the rest lists installed kernel packages.

pveversion -v | head -n 1
pveversion -v | grep -E 'proxmox-kernel|proxmox-default-kernel'

3. What the boot loader will pick next time. On hosts managed by proxmox-boot-tool, list the kernels selected for booting and check for a pin.

proxmox-boot-tool kernel list

4. A quick pass or fail check you can paste on every node.

r=$(uname -r)
case "$r" in
  7.0.14-*-pve)
    b=${r#7.0.14-}; b=${b%-pve}
    if [ "$b" -ge 24 ]; then echo "OK: running $r"; else echo "NOT FIXED: running $r"; fi ;;
  *) echo "CHECK: running $r is not a 7.0.14 build, see PSA-2026-00068-1" ;;
esac

5. The whole cluster at once. From any node with root SSH to the others (the Proxmox cluster sets this up), loop over node names.

for n in pve1 pve2 pve3; do
  printf '%s: ' "$n"; ssh root@"$n" uname -r
done

Patch a single node

For a standalone host or homelab box with nowhere to move guests. Expect downtime for every guest.

1. Check your repository. Build 24 reached pve-no-subscription first and enterprise after. Proxmox's repository docs recommend pve-enterprise for production and warn no-subscription packages "are not always as heavily tested and validated."

cat /etc/apt/sources.list.d/*.sources | grep -E 'URIs|Components'

2. Back up first. Back up important guests and confirm the jobs finished.

3. Use full-upgrade, not upgrade. The admin guide warns that on Proxmox's rolling release, a plain apt upgrade can leave a partly upgraded or broken package state.

apt update
apt full-upgrade

4. Confirm a 7.0.14 kernel is installed. A full upgrade on Proxmox VE 9 normally brings in the default kernel. If the list shows no 7.0.14 build of 24 or later, install the 7.0 package as Proxmox's opt-in announcement described.

apt install proxmox-kernel-7.0
proxmox-boot-tool kernel list

5. Clear any old pin. A pinned older kernel keeps booting after the update. Remove the pin, then refresh, which the admin guide requires after any pin change.

proxmox-boot-tool kernel unpin
proxmox-boot-tool refresh

6. Check DKMS modules before rebooting. A forum user reported NVIDIA driver 615.78.08 failing to compile against 7.0.14-24-pve.

dkms status

7. Shut guests down cleanly and reboot.

pvenode stopall
reboot

8. Verify with uname -r and the pass or fail check, then start guests without start on boot set.

If the new kernel will not boot, pick the previous one from the boot menu and fix the cause quickly. A one-time pin is a bridge, not a fix.

Roll a cluster with live migration and HA

With spare capacity you can patch a cluster without guest downtime. The HA documentation is blunt about package updates: one node at a time, check it, "never all at once."

Before you start

• Quorum. The cluster manager needs a majority of votes online. A three node cluster stays quorate with one node down; a two node cluster without a QDevice does not. Check with pvecm status.
• Matching CPUs. The cluster docs say online migration is only supported between CPUs from the same vendor. Check the CPU type set on your VMs if your nodes differ.
• Storage. Guests on shared storage move quickly; local disks must be copied and take much longer.
• Guests that cannot move. Passthrough VMs and HA resources with strict node affinity stay put. Give them a window.
• Direction. Proxmox's 8 to 9 upgrade guide says older to newer migration always works, while newer to older "may work, but is generally not supported." A full upgrade updates QEMU too, so move guests onto already patched nodes.

How HA treats a plain reboot

This trap catches people. The HA shutdown policy, set under Datacenter, Options, HA Settings or as ha: shutdown_policy=... in datacenter.cfg, decides what happens to HA guests when a node goes down.

So with the default, typing reboot gives every HA guest on the node an outage for the length of the reboot. Use maintenance mode instead.

The rolling procedure

1. Check cluster health. Confirm quorum, and on hyperconverged Ceph confirm the cluster is healthy.

pvecm status
ceph -s

2. Pick the first node, ideally the one with the fewest guests, so later migrations land on a fixed host.

3. Enable HA maintenance mode. The HA manager moves HA guests to other nodes per your rules. Run it from any node.

ha-manager crm-command node-maintenance enable pve1

The status flips when the request is picked up, not when guests have moved. Wait until no HA guests remain, or for the log line watchdog closed (disabled).

4. Move the guests HA does not manage. Maintenance mode only moves HA resources. Move the rest by hand.

# one VM, live, to a named node
qm migrate 101 pve2 --online
# everything left on this node, a few at a time
pvenode migrateall pve2 --max-workers 2
# include guests on local disks (slower)
pvenode migrateall pve2 --max-workers 2 --with-local-disks 1

5. On Ceph, consider noout. It stops Ceph marking the rebooting node's OSDs out and rebalancing. Proxmox documents it for a full cluster shutdown; many operators also use it for single node reboots.

ceph osd set noout

6. Update and reboot the empty node.

apt update && apt full-upgrade
proxmox-boot-tool kernel list
dkms status
reboot

7. Verify before moving anything back. uname -r must show 7.0.14-24-pve or later; on Ceph, wait for ceph -s to settle, then clear noout.

uname -r
pvecm status
ceph osd unset noout

8. Leave maintenance mode. A reboot does not clear it. Disabling it moves the node's HA guests back.

ha-manager crm-command node-maintenance disable pve1

9. Repeat, migrating each next node's guests onto patched nodes, until every node passes. Work inside tmux or screen, as the upgrade guide recommends, so a dropped SSH session cannot strand a half finished upgrade.

Homelab versus production

The same fix applies everywhere, but the risk and the right pace differ.

In a homelab, PwnEscape needs code running inside a guest. If every guest is yours the risk is lower, not zero: a compromised web service in a VM is a guest an attacker controls. Patch this week.

In production, the hosts that matter most run guests you do not control: customer VPSs, CI runners building untrusted pull requests, code sandboxes. One forum poster running a VPS platform on Proxmox said they rolled the update across their hosts straight away.

If a host is on an end of life series

• Proxmox VE 9 on 6.17 or 6.14. Install the 7.0 kernel, clear any pin, reboot. If you pinned 6.17 for a known issue, test 7.0 on one node first; the roadmap notes a RAID issue in the 7.0 kernel on the 9.2 installer that later 7.0.14 builds fixed.
• Proxmox VE 8. The real fix is upgrading to 9. The official guide requires the latest 8.4 packages (at least 8.4.1), a clean run of the pve8to9 checklist with its full option, Ceph on Squid if hyperconverged, then a node by node switch from Bookworm to Trixie. That is a project, not a same day patch. Building fresh 9.x nodes and live migrating guests across also works, since older to newer is the supported direction.
• Meanwhile. Move untrusted guests off end of life hosts first. TuxCare suggested turning off virtio-net checksum offload as an interim step but has not tested it, and SmartScope advises against relying on it. TuxCare listed no live patch for Debian or Proxmox kernels. A forum user offered a self built live patch for 6.8; it is unofficial and we would not rely on it.
• Proxmox VE 7 and older reached end of life in 2024 or earlier.

What would have helped

Practices any team can use

• A kernel inventory per node. A nightly job that records uname -r, the installed proxmox-kernel packages and any boot pin turns "which hosts are exposed" into a lookup instead of a scramble. The pass or fail script above is a starting point.
• Staying on a supported series. The teams with the shortest path this week were those already on Proxmox VE 9 with the 7.0 kernel. Hosts left on 8 after its August 2026 end of life now face an upgrade project under time pressure.
• Monthly rolling reboots with one node of spare capacity. Maintenance mode, migration, Ceph flags and DKMS builds then get tested before an incident, not during one.
• Separating trust levels. Untrusted guests on their own nodes tell you which hosts to patch first.

Where Safeguard fits

Plainly: Safeguard does not patch Proxmox hosts, does not inventory the kernels your hypervisors are running, and cannot tell you which node still needs a reboot. Our scanning covers source repositories, container images and SBOM files. A container image does not contain the host kernel it runs on, so scanning images will never flag PwnEscape on the node underneath. For this fix, Proxmox's advisory, your repository and your own node inventory are the tools.

Where Safeguard does help this week:

• Writing the rollout with a human in the loop. The Safeguard CLI's assistant can edit files and run commands with your approval. Ask it to turn the procedure above into a script for your nodes and review each command first. /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict; use Ask or Strict near a hypervisor.
• Approving from anywhere. The desktop and phone apps can send work to a computer running the CLI and approve each command, useful for night windows.
• The rest of the queue. PwnEscape arrived the same week as PHP2Shell, which does live inside your images and repos. safeguard scan --image NAME, safeguard scan --dir . or safeguard scan --sbom FILE match what you ship against vulnerability databases, the platform shows which projects contain a given component and version, and reachability analysis helps you order the work.

None of this would have prevented PwnEscape or replaced the reboot. To try the CLI for the parts it does cover, get it from safeguard.sh/download and read the CLI documentation.

Zero-Day Discovery and Gold

Two Safeguard capabilities are built for the "before the CVE" and "pull a safe version" parts of incidents like this, so it is worth being exact about what they are and what they did not do here.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages, and an artifact loses its badge on regression. It does not ship hypervisor kernels.

The habit these tools support is the same one this incident rewards: pull patched, signed components from a curated source and rebuild and redeploy fast. For Proxmox hosts the curated source is Proxmox's own repository, and the redeploy is a reboot.

Related: how AI found PHP2Shell and PwnEscape, hosting concentration risk in the IDCF Cloud ransomware incident, and October 2026 security incidents and what would have helped.

Common mistakes and troubleshooting

• Running apt upgrade instead of apt full-upgrade. The admin guide warns this can leave packages partly upgraded. Use full-upgrade.
• Installing the kernel and not rebooting. The package is on disk and the host is still running the old kernel. Only uname -r tells the truth.
• A forgotten kernel pin. A host pinned to 6.17 will boot 6.17 after the update. Run proxmox-boot-tool kernel list, then unpin and refresh.
• Stopping at build 22 or 23. Build 22 had an earlier variant of the fix. The advisory names build 24.
• Rebooting an HA node without maintenance mode. With the default conditional policy, HA guests freeze and wait for the node. Enable maintenance mode first, and remember to disable it afterwards.
• Migrating guests from a patched node back to an unpatched one. Newer to older migration is not supported in general, and it puts the guest back on a vulnerable host.
• Missing DKMS modules after reboot. If a GPU or storage driver did not build, the node comes up without it. Check dkms status before you reboot, not after.
• Patching guest kernels instead of the host. Updating the kernel inside a VM does nothing for PwnEscape. The fix belongs on the Proxmox node.

FAQ

Which Proxmox kernel fixes PwnEscape?

proxmox-kernel-7.0.14-24-pve, or its signed variant, and any later build in the 7.0.14 series. That is the only fixed version named in Proxmox's advisory PSA-2026-00068-1, published 16 October 2026.

Is Proxmox VE 8 getting a fix?

No, according to Proxmox staff on the forum. Proxmox VE 8 reached end of life in August 2026, its kernel series are end of life, and the 7.0 kernel is not offered for the 8 series. The fix is upgrading to Proxmox VE 9.

Do I need to reboot?

Yes. The kernel must be running, not just installed. Proxmox has not announced a live patch, and TuxCare listed none for Debian or Proxmox kernels. In a cluster, live migrate guests away first so the reboot costs them nothing.

Is pve-no-subscription safe to use for this?

The fix appeared there first, on 16 October, and a subscriber reported it on pve-enterprise on 17 October. Proxmox recommends enterprise for production. For a homelab, no-subscription is the normal choice.

Will HA move my VMs automatically when I reboot?

Not with the default conditional policy. On a reboot, HA guests are frozen and restart on the same node afterwards. Use ha-manager crm-command node-maintenance enable first, or set the shutdown policy to migrate.

Are LXC containers on Proxmox affected?

Containers share the host kernel, so the fix is the same host kernel update. The advisory describes the virtio path used by KVM guests, but TuxCare notes that packets arriving through TAP and AF_PACKET can also carry the offload hints involved. Do not assume containers are out of scope; patching the host covers both.

I rent a VPS from a provider that uses Proxmox. What should I do?

You cannot patch the host yourself. Ask the provider which kernel its hosts run and when they will reboot, and check whether your VPS restarts automatically afterwards.

See how Safeguard would have helped

These demos show Safeguard's own tools on other tasks, not on this incident. Each intro says how the same flow carries over to a Proxmox rollout.

The first demo is a real CLI session in a code repository: the assistant reads a lodash finding, asks before each command, edits package.json, runs the install and tests with your approval, and pushes nothing. For PwnEscape you would open the same CLI in your infrastructure repo and ask it to write a drain, update, reboot and verify script for your node names; with Ask or Strict permissions it stops before every command.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit, and it ends with an upgrade done and tests passing. For a Proxmox rollout, the folder would hold your runbook or Ansible files, and each step that touches a node would wait for your Approve.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve a command on the phone with Allow once, Allow for turn or Deny. Kernel reboots often happen in a night window, so this is how the person on call could approve the next node's reboot, or deny it if the last node did not come back cleanly.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Proxmox forum: Proxmox VE security advisories, PSA-2026-00068-1
• Proxmox forum: CVE-2026-99999 or the Vercel KVM Zero-Day (staff replies)
• Proxmox forum: KVM Escape CVE-2026-99999
• Proxmox pve-kernel changelog
• Proxmox forum: Opt-in Linux 7.0 kernel for Proxmox VE 9 available
• Proxmox VE wiki: FAQ (support lifecycle)
• Proxmox VE wiki: Roadmap
• Proxmox VE wiki: Package repositories
• Proxmox VE wiki: Upgrade from 8 to 9
• Proxmox VE admin guide: Host system administration
• Proxmox VE admin guide: High availability
• Proxmox VE admin guide: Cluster manager
• Proxmox VE admin guide: Ceph
• Proxmox VE manual: pvenode
• Proxmox VE manual: qm
• pwn.ai: PwnEscape, guest-to-host KVM escape (CVE-2026-99999)
• TuxCare: PwnEscape KVM guest escape
• SmartScope: CVE-2026-99999 PwnEscape affected versions and status

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.