uname -r prints 7.0.14-24-pve on a host that is still missing CVE-2026-98432. The next two Proxmox kernels have the fix. 7.0.14-25-pve and 7.0.14-26-pve include the commit, and a Proxmox staff member said both were on the enterprise repository as well as no-subscription and test. The host is patched when that command shows 7.0.14-25 or newer after a reboot.
uname -r | What is answering packets |
|---|---|
7.0.14-26-pve, or a later 7.0 | The running kernel has the fix |
7.0.14-25-pve | The running kernel has the fix |
7.0.14-24-pve or an older 7.0.14 | The build from before the Ubuntu source bump |
| Any other series, or a pinned kernel | Boot the 7.0.14-25 line, or read the pin before you call it done |
What 7.0.14-24 is still running
CVE-2026-98432 is a use-after-free in the kernel's IPv4 TCP code. The kernel announcement describes a retransmitted SYN racing the moment a connection request becomes a full socket. The IP options on that request can be freed while another CPU is still reading them. The fix frees those options after an RCU grace period. The same note lists the bug as introduced in 4.4, and names fixed stable kernels including 6.12.113 and 7.2.10.
Red Hat's bulletin calls it Critical. A remote attacker needs no account and no user on the box. They do need to win a race on a host that accepts TCP. Red Hat's description of the result is remote code execution, and their mitigation line is the one to keep: filtering traffic can shrink the window, and the kernel update is the fix.
Proxmox builds this kernel from Ubuntu's source, which is why a Debian-based installer can still be waiting on an Ubuntu kernel package. In the forum thread, the chain people traced puts the Ubuntu backport inside Ubuntu-7.0.0-43.43, and the first Proxmox build on that source is 7.0.14-25. Fabian answered the confirmation question in that thread: the fixing commit from the CVE announcement is in 7.0.14-25 and 7.0.14-26. He also said those two versions were on the enterprise repository.
The 7.0.14-25 changelog says the source moved to Ubuntu-7.0.0-43.43i1 and that the bump carries other security fixes. A search of that entry for CVE-2026-98432 comes up empty. Fabian's reply is what ties the commit to this number.
Check the running kernel
On each Proxmox VE node, and on each Proxmox Backup Server:
uname -rThen see what is installed, and whether a pin will ignore it:
pveversion -v | grep -i kernel
proxmox-boot-tool kernel listPBS lists its packages with proxmox-backup-manager versions --verbose. A pin is a line in that kernel list. The host will keep booting the pinned version after apt has unpacked 7.0.14-26. Clear it before the reboot:
proxmox-boot-tool kernel unpin7.0.14-25-pve and 7.0.14-26-pve are the two versions Fabian named. A later 7.0 build is past them. Anything else on uname -r still needs a boot into one of those kernels.
Update, then reboot one node
apt upgrade can leave a kernel dependency behind. Proxmox's own upgrade path is the full upgrade:
apt update
apt full-upgradeThe web interface button that says Upgrade runs that path. Afterwards the package you want installed is proxmox-kernel-7.0.14-26-pve-signed, or the -25 package if that is the one the repository handed you. Both contain the commit. Then reboot. Until uname -r changes, the old kernel is the one accepting TCP.
A single node takes its guests down with it. Pick a window, and have a backup that is newer than the last time you were willing to rebuild.
In a cluster, empty the node before you reboot it. Maintenance mode is the HA tool built for a kernel install. Run it from any node, with the name of the node you are about to reboot:
ha-manager crm-command node-maintenance enable node1
ha-manager statusThe HA page is blunt about the status line. It can say maintenance as soon as the node accepts the request, which is earlier than the moment the last guest has left. Wait until no HA service is still running there. A VM with its disk on shared storage, or with a replication job, can move while it keeps running. A container comes back up on the other node. Guests that are not in HA stay where you put them, so migrate those yourself.
Reboot, then:
uname -rYou want 7.0.14-25-pve or newer. On a Ceph node, wait until the cluster is healthy before you take the next node. Recovery is the busy moment, and stacking a second reboot on top of it is how a kernel update becomes a quorum problem.
Maintenance mode survives the reboot. The HA page says it stays until you turn it off. Guests that moved away stay away until you do:
ha-manager crm-command node-maintenance disable node1They move back to the node they were on when you enabled it. Leave the previous kernel installed. If 7.0.14-26 fails to boot, the boot menu still has 7.0.14-24, and you would rather have that than a host that does not come up.
Guests do not inherit the host kernel
LXC uses the host kernel. After the reboot, a container on that node is running the fixed code. It does not get a second kernel of its own.
A virtual machine does. Debian's tracker marks the fix in bookworm-security at linux 6.1.190-1, and in trixie-security at linux 6.12.113-1. Bookworm also has a newer-series package, linux-6.12 6.12.113-1~deb12u1. A Debian guest is done when its own uname -r is at or past the version in that row, and after its own reboot.
Ubuntu is a different clock. Canonical's tracker still had 22.04, 24.04, 26.04, and 26.10 listed with the fix in progress. Red Hat lists Enterprise Linux 8, 9, and 10 as affected, says 7 is not, and tells you to install the kernel update when they publish it. A Windows guest is outside this CVE. The Linux guests you sell are not, and the Proxmox reboot does not patch them.
| Guest | Fixed when |
|---|---|
| LXC on the Proxmox host | The host has rebooted into 7.0.14-25-pve or newer |
| Debian 12 | linux 6.1.190-1 in bookworm-security, then a guest reboot |
| Debian 13 | linux 6.12.113-1 in trixie-security, then a guest reboot |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Canonical still had the fix in progress. Check the tracker again |
| RHEL 8, 9, 10 | Red Hat's kernel update, once they ship it. RHEL 7 is outside the bug |
Proxmox Backup Server is the same kernel package on a machine that is often not in the HA cluster. Update it the same way, wait until no backup task is running, and reboot it. A backup server left on 7.0.14-24 is still accepting TCP on the old kernel.
If the reboot has to wait
Red Hat's guidance is to install the kernel update as soon as there is one, and that a traffic filter can reduce exposure while you schedule the window. The filter is a stopgap. It can also break workloads that actually send the packets you drop. It does not change uname -r.
Keep port 8006 and SSH on a management network. A host with the web interface open to the internet is accepting TCP from everyone, which is the surface this bug cares about. How that node is attached in the first place is the platforms and nodes guide.
Before you tell a customer it is patched
Which Proxmox kernel fixes CVE-2026-98432?
7.0.14-25-pve and 7.0.14-26-pve, and any later 7.0 build. Fabian confirmed that those two include the commit from the kernel announcement, and that both were on the enterprise repository.
The package is installed. Is the host patched?
When uname -r still prints 7.0.14-24-pve, the old kernel is running. Reboot. If it prints the old version again after the reboot, proxmox-boot-tool kernel list is where a pin shows up.
Does Proxmox Backup Server need the same kernel?
Yes. PBS uses the Proxmox kernel packages. Update, let the running backup finish, reboot, and check uname -r.
Do containers and VMs need their own update?
Containers follow the host after the host reboots. Linux VMs run their own kernel. Debian 12 wants 6.1.190-1 from bookworm-security. Debian 13 wants 6.12.113-1 from trixie-security. Ubuntu and RHEL 8, 9, and 10 were still on their own schedules.
Does maintenance mode turn itself off after the reboot?
No. The HA manual says manual maintenance mode stays until you disable it or clear the manager status. Guests that moved for the reboot stay on the other node until ha-manager crm-command node-maintenance disable runs.