CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP connection setup code. Red Hat rates it Critical with a preliminary CVSS score of 9.8, because an unauthenticated attacker can reach it over the network with nothing more than crafted TCP traffic. Some third-party trackers list it lower (5.9) because the attacker has to win a race inside the kernel. Red Hat published bulletin RHSB-2026-016 on 30 October 2026 and CloudLinux posted its status the same day.
Unlike last week's ZDI-CAN-33367 local root, this one does not need a shell account or a compromised WordPress site. Any server accepting IPv4 TCP connections, which is every hosting server, runs the vulnerable code. No exploitation in the wild has been reported and no exploit is public.
What the bug does
When the kernel turns a pending connection into a full socket, tcp_v4_syn_recv_sock() hands the IP options to the child socket without copying them. A retransmitted SYN arriving at the same moment can still be reading those options to build a SYN-ACK when the child socket is freed. The options are released with a plain kfree() instead of after an RCU grace period, so ip_options_build() reads freed memory. A similar path exists in request socket migration (net.ipv4.tcp_migrate_req=1 or a BPF reuseport program).
The upstream fix frees both option structures with kfree_rcu(). IPv6 is not affected by the main path.
The flaw was reported by Anthropic, which posted on 27 October that it had built an exploit giving remote root on servers with a Multipath TCP (MPTCP) listener. CloudLinux's kernel team could not reproduce that claim. MPTCP is off by default on CloudLinux 8, 9, and 10, but turning it off does not remove the bug, because the race is in ordinary TCP code.
sysctl net.mptcp.enabled
Which CloudLinux versions are affected
| Version | Kernel | Fixed kernel (30 October) | KernelCare |
|---|---|---|---|
| CloudLinux 7 | 3.10 | Not affected | — |
| CloudLinux 7 hybrid | 4.18 | 4.18.0-553.180.1.lve.1, staged rollout | In preparation |
| CloudLinux 8 | 4.18 | 4.18.0-553.180.1.lve.1, staged rollout | In preparation |
| CloudLinux 8 LTS / 9 LTS | 5.14 (TuxCare ELS) | kernel-lts els19, staged rollout | Not available |
| CloudLinux 9 | 5.14 | 5.14.0-687.61.2.el9_8, AlmaLinux testing | In preparation |
| CloudLinux 10 | 6.12 | 6.12.0-211.69.2.el10_2, AlmaLinux testing | In preparation |
| CloudLinux for Ubuntu 22.04 | 5.15 | Not released; Canonical fix in progress | Not available |
CloudLinux 7 is safe only because the vulnerable code arrived in Linux 4.4. That is not a reason to stay on it: plan the move to CloudLinux OS 10.
Install the fixed kernel now
Staged rollout means the kernel reaches your servers over several days. To install it today on CloudLinux 7 hybrid or 8:
yum update cloudlinux-release
yum update kernel --enablerepo=cloudlinux-rollout-3-bypass
reboot
On CloudLinux 9, pull the kernel from AlmaLinux testing, then disable the repo again so nothing else comes from it:
rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
dnf config-manager --disable almalinux-testing
reboot
On CloudLinux 10:
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
dnf config-manager --disable almalinux-testing
reboot
After the reboot, uname -r should start with 4.18.0-553.180.1 (CloudLinux 7 hybrid and 8), 5.14.0-687.61.2 (9), or 6.12.0-211.69.2 (10). The LTS kernels for CloudLinux 8 LTS and 9 LTS are 5.14.0-284.1101.el8.tuxcare.11.els19 and 5.14.0-284.1101.el9.tuxcare.11.els19, and they also need a reboot.
Mitigate before you can reboot
There is no sysctl that fixes this. Red Hat's only interim measure is an nftables rule that drops incoming IPv4 TCP packets carrying IP options, which ordinary web, mail, and SSH traffic doesn't use. Save this as cve-2026-98432.nft:
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}
Validate it, load it, and confirm it is active:
nft --check --file cve-2026-98432.nft
nft --file cve-2026-98432.nft
nft list table inet cve_2026_98432
The rule only lasts until the next reboot, which is when you boot the fixed kernel anyway. Red Hat warns it may break workloads that rely on IP options, so try it on one server first. Once patched, remove it with nft delete table inet cve_2026_98432.
KernelCare status
Livepatches for CloudLinux 7 hybrid, 8, 9, and 10 were in preparation on 30 October. There will be none for the LTS kernels or CloudLinux for Ubuntu 22.04, so those servers need a reboot. Once the patch ships:
kcarectl --update
kcarectl --patch-info | grep CVE-2026-98432
Use --patch-info, not --info, which doesn't list CVEs and can make a patched server look unpatched. ePortal users need to sync the feed, and servers running Imunify360 may already have KernelCare included.
What is CVE-2026-98432?+
Is CloudLinux 7 affected by CVE-2026-98432?+
Does disabling MPTCP fix CVE-2026-98432?+
How do I mitigate CVE-2026-98432 without rebooting?+
Is there a KernelCare patch for CVE-2026-98432?+
Next steps
- Two kernel advisories in a week is the case for livepatching: see live patching for hosting fleets and add a KernelCare license to every node.
- Check you have also closed ZDI-CAN-33367, which needs a different fix.
- Renew or add servers on a CloudLinux license before the reboot window.