Proxmox CVE-2026-98432: check your kernel, update to 7.0.14-25 or later, reboot

Proxmox CVE-2026-98432 is a Linux kernel bug in IPv4 TCP handling, and Proxmox VE and Proxmox Backup Server hosts on kernel 7.0.14-24-pve or older are affected. The fix is in proxmox-kernel 7.0.14-25 and later. A Proxmox staff member confirmed on 30 October 2026 that both 7.0.14-25 and 7.0.14-26 contain the fixing commit. Run uname -r, update, and reboot.

Google Trends showed "proxmox cve-2026-98432" as a rising search under "proxmox" on 30 October 2026, up 18,800%. This post covers how to check a host, which kernel to install, how to reboot a cluster without downtime, and what the temporary mitigation costs you.

What CVE-2026-98432 is

The NVD entry, published on 15 October 2026, describes a use-after-free in the kernel's IPv4 TCP code. When a retransmitted SYN arrives while the kernel is turning a connection request into a full socket, the IP options attached to the request can be freed while another CPU still reads them. The fix makes the kernel wait for an RCU grace period before freeing them.

The NVD record lists kernels from 4.4 onward as affected. Fixed upstream stable versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.

Scores differ. The kernel CNA score shown on NVD is CVSS 3.1 9.8. Red Hat rates it 8.1 because it sets attack complexity to high. Red Hat says a remote attacker could send specially timed requests, and that the main result is a crash (denial of service) or possible memory corruption.

On 29 October 2026 the Go security team wrote on oss-security that a publicly described exploit got remote code execution against a server with a Multipath TCP (MPTCP) listener. The same message says the bug itself is not specific to MPTCP, and that systems without MPTCP listeners may be open to similar attacks.

Is Proxmox affected?

Yes. The Proxmox kernel is built on Ubuntu's kernel source. In the Proxmox forum thread opened on 29 October 2026, community member bbgeek17 traced the fix from upstream into Ubuntu's 7.0.0-43.43 source and from there into the Proxmox kernel. The pve-kernel git history shows the move to that source in the commit "update sources to Ubuntu-7.0.0-43.43i1" on 17 October 2026, and the version bump to 7.0.14-25 the same day.

A Proxmox staff member (forum user fabian) then confirmed in the thread on 30 October 2026 that "the fixing commit from the official CVE announcement is included" in 7.0.14-25 and 7.0.14-26. He also said both kernels are now on the enterprise repository. They were already in the no-subscription and test repositories.

Proxmox Backup Server uses the same kernel packages. The PBS no-subscription repository for Debian Trixie lists proxmox-kernel-7.0.14-25-pve-signed and 7.0.14-26-pve-signed, as we saw in the package index on 30 October 2026.

Not covered by that confirmation: the older opt-in series still in the Proxmox VE 9 repository (6.17 and 6.14) and the 6.8 kernels of Proxmox VE 8. I found no statement about them. If you run one of those, move to the 7.0 default kernel or check the package changelog yourself.

Check your hosts

On each Proxmox VE and PBS host, run:

uname -r

7.0.14-25-pve, 7.0.14-26-pve or a later 7.0 build means the running kernel has the fix. Anything from 7.0.14-24-pve down does not.

To see which kernels are installed and which one boots next:

pveversion -v | grep -i kernel      # Proxmox VE
proxmox-boot-tool kernel list       # shows a pinned kernel, if any

On PBS, proxmox-backup-manager versions --verbose lists the same packages. If a kernel is pinned, the host keeps booting the old one after an update. Remove the pin with proxmox-boot-tool kernel unpin.

The mitigation repo's author noted on 30 October 2026 that the pve-kernel changelog had no entry for this CVE, so apt changelog will not show it by name. The staff reply in the forum thread is the confirmation.

Update and reboot

1. Update the package lists and upgrade the whole system. On Proxmox use apt update then apt full-upgrade (or the Upgrade button in the web interface). Plain apt upgrade can leave packages behind, see apt upgrade vs dist-upgrade on Proxmox.
2. Check that proxmox-kernel-7.0.14-26-pve-signed (or -25) is installed.
3. Reboot. The fix only applies after the host boots the new kernel. Run uname -r again afterwards.

On a single homelab node, schedule a short window and reboot. Guests stop with the host.

In a cluster, empty the node first. Live-migrate running VMs to another node, or put the node in HA maintenance mode with ha-manager crm-command node-maintenance enable <node> so HA moves its guests. LXC containers cannot live-migrate; they restart on the target node. Reboot, check uname -r, disable maintenance mode, then do the next node. If you run Ceph, wait for the cluster to return to HEALTH_OK before moving on.

Back up first if your last good backup is old, and keep the previous kernel installed so you can pick it in the boot menu if the new one fails. The move to kernel 7.0 caused container trouble for some users, covered in kernel 7.0 broke the containers.

Your VMs need their own patch

LXC containers share the host kernel, so they are covered once the host runs 7.0.14-25 or later.

Virtual machines are different: each Linux VM runs its own kernel and needs its distribution's fix. The Debian security tracker lists fixed versions 6.1.190-1 for Debian 12 Bookworm (security) and 6.12.113-1 for Debian 13 Trixie (security). The mitigation repo said on 29 and 30 October 2026 that Ubuntu and RHEL 8, 9 and 10 had no fixed kernel yet. Check your vendor's tracker for the current state.

Temporary mitigation, and what it costs

If a host cannot reboot this week, there are two stopgaps. Neither replaces the kernel update.

The first is the typhoon1217/cve-2026-98432-mitigation scripts. They add nftables rules that drop IPv4 TCP packets carrying IP options and set net.mptcp.enabled=0. The author says the bug cannot trigger without such packets on hosts without SELinux or Smack CIPSO labelling. The trade-offs, from the repo itself:

• It is a single administrator's work, not tested against a real exploit, and not endorsed by any vendor.
• nftables state is per network namespace. Host rules do not protect LXC or Docker containers; a separate script injects the rules into running containers, and that injection is lost when a container restarts.
• When it gets in the way, connections hang instead of being refused, which is harder to diagnose.
• A flush ruleset in another firewall config wipes the rules on reload.

The second is turning off MPTCP in the programs you run. The Go security team notes that Go 1.24 and later enable MPTCP by default for listening sockets on Linux, and that GODEBUG=multipathtcp=0 turns it off. The same message calls this a fragile mitigation: one forgotten MPTCP listener leaves the system open, and it assumes every exploit needs MPTCP.

Either way, keep the management interface off the internet. Port 8006 and SSH should only be reachable from a management network or a VPN; see remote Proxmox with zero inbound access.

Exploitation status

CVE-2026-98432 was not in the CISA Known Exploited Vulnerabilities catalog when we checked the feed on 30 October 2026. OpenCVE showed an EPSS score below 1% and no KEV listing. The mitigation repo says no in-the-wild exploitation had been reported as of 29 October 2026.

For the routine side of keeping up with Proxmox kernels, see Proxmox kernel updates are exhausting.