Technology & security · · 8 min read · By Alexander
Critical Linux TCP vulnerability: What should website operators do now?
CVE-2026-98432 affects TCP processing in the Linux kernel, the core of the operating system. Linux-CNA and Red Hat rate the vulnerability as critical, with a CVSS 3.1 score of 9.8 out of 10. Ask your hosting provider to confirm the corrected package version and that the fix is active in the running kernel. Research status: 3 November 2026.
What happened in Linux?
CVE-2026-98432 is a use-after-free vulnerability: the kernel may release memory for certain IPv4 options too early while another process is still accessing it. The TCP connection setup is affected. The upstream fix dates from 5 October 2026; the Linux CNA record was published on 15 October and updated on 3 November.
Exploitation requires a reachable IPv4 TCP service listening for connections and specially crafted SYN packets with IPv4 Record Route or Timestamp options. These IP options are not ordinary TCP timestamps. Exploitation relies on competing connection and retransmission processes. A login, local privileges or a click by the operator are not required: processing takes place in the kernel before application authentication. A normal website visit is not an established trigger.
“StackWarp” refers to a different research project concerning AMD-SEV virtualisation and CVE-2025-29943. Use the identifier CVE-2026-98432 for the TCP vulnerability discussed here.
How dangerous is CVE-2026-98432 in practice?
Possible consequences include a kernel crash, information leakage and, under suitable conditions, third-party code running in the kernel context, meaning with the highest system privileges. Reliable remote code execution (RCE) requires further exploitation conditions. The 9.8 rating comes from Linux-CNA and Red Hat. SUSE rates the same CVE at 8.1 under CVSS 3.1 based on a higher assumed attack complexity, and also at 9.2 under CVSS 4.0. The versions and rating assumptions must be distinguished.
On 27 October, Anthropic documented successful RCE with root privileges in a research setup using an MPTCP listener. According to Red Hat, the underlying vulnerability also exists without MPTCP. The research proof does not demonstrate a reliable attack on every ordinary web server. A scan or attempted attack alone also does not prove a successful breach.
The primary sources reviewed provide no reliable confirmation of active exploitation as of 3 November 2026. The CVE is absent from the checked CISA catalogue of known exploited vulnerabilities, version dated 30 October 2026. These findings prove neither the absence of attacks nor the protection of your server.
Which kernel versions fix this vulnerability?
The following list gives the first corrected upstream versions according to Linux-CNA. It cannot be applied directly to distribution kernels: vendors may incorporate fixes into packages with an older base version number. The product branch, complete package version and vendor advisory are decisive.
Red Hat released corrected packages on 1 November: for RHEL 8.10 `kernel-4.18.0-553.182.1.el8_10`, for RHEL 9.8 `kernel-5.14.0-687.64.1.el9_8` and for RHEL 10.2 `kernel-6.12.0-211.72.1.el10_2`. According to Red Hat, RHEL 7 is not affected because it does not contain the vulnerable code; this says nothing about its general security status.
Debian confirms security updates for Debian 12 (`linux`: `6.1.190-1`; `linux-6.12`: `6.12.113-1~deb12u1`) and Debian 13 (`linux`: first fix `6.12.113-1`). For Ubuntu 22.04, 24.04 and 26.04, target packages for generic kernels are documented in the `-proposed` test channel, but no general stable release is confirmed here. For Ubuntu 26.10, the discrepancy between the blog and the newer tracker remains unresolved. Have the specific package name and branch checked.
- Upstream 5.10: fixed from 5.10.272
- Upstream 5.15: fixed from 5.15.223
- Upstream 6.1: fixed from 6.1.190
- Upstream 6.6: fixed from 6.6.159
- Upstream 6.12: fixed from 6.12.113
- Upstream 6.18: fixed from 6.18.56
- Upstream 7.2: fixed from 7.2.10; mainline fix in 7.3
The omission of older upstream series is not an all-clear; their support requires separate evidence from the vendor. Cloud, real-time, HWE, FIPS and other special kernels must be checked separately.
How can you check whether your website is affected?
The kernel beneath the website is what matters. AWS explicitly includes WordPress, LAMP and Plesk images among the cases that should be checked. Checking the version of WordPress, plugins, nginx or Apache does not replace checking the kernel.
With shared or managed hosting, ask the provider to identify the operating system and maintenance status. For self-managed VPS or cloud servers, you or your administrator must perform the check. Docker containers share the host kernel; a new container does not fix it. Virtual machines have their own kernels: the host and guest may need to be checked separately.
Administrators can use `uname -r` to identify the running kernel. They must also determine the complete package version: with `dpkg-query` on Debian/Ubuntu and `rpm -q` on RPM-based systems. On Debian, the source package version also helps when comparing the system with the advisory. Retain the distribution suffix and package name; a package that is not found does not provide an all-clear. An installed package alone does not prove that the fix is active.
Plesk’s system update function excludes kernel packages. An “up to date” status in the panel is therefore not enough. cPanel’s general Security Advisor is also not CVE-specific evidence. If you have restricted permissions, involve the provider.
What should you write to your hosting provider?
Add your domain or customer number and send this request:
“Hello, is the Linux kernel used by my hosting service or server affected by CVE-2026-98432? Please provide the distribution, kernel branch, complete corrected package version, kernel actually running and the relevant vendor advisory. Is the fix active following a restart or through a loaded live patch that is suitable for this CVE? Where applicable, please consider the virtualisation host, VM guest and container host kernel. If the fix is still pending: which vendor-documented interim measure is active, what limitations does it have, and when will the update and required maintenance window take place? Please include the date of the check in your reply.”
Red Hat, SUSE, Canonical and AlmaLinux specify a restart for the kernel updates described. A live patch would be an alternative only with evidence that it covers this CVE and the running kernel. The research did not confirm a corresponding Ubuntu Livepatch or Red Hat kpatch; a green service status is not sufficient.
What should you do if the kernel update cannot be applied immediately?
The vendor-approved update takes priority. Arrange a maintenance window. Have the correct package installed and, after the required restart, check the running kernel again and match it to the corrected package.
Red Hat documents a filter for TCP traffic with IPv4 options. It reduces the attack surface but explicitly does not prevent attacks completely. Network namespaces, containers and actual packet paths may limit its effect. An administrator must test the vendor rule for the specific environment; it does not replace an update. According to Canonical, disabling MPTCP alone is not sufficient.
The primary sources reviewed provide no evidence that Cloudflare or a Web Application Firewall (WAF) offers comprehensive protection against this CVE. The flaw affects the network and kernel layers. If neither an update nor an effective restriction of reachability is possible, temporary isolation or shutdown remains a last resort to be agreed with the operator.
Frequently asked questions about the Linux TCP vulnerability
Are up-to-date WordPress plugins sufficient?
No. Plugin updates do not prove that the running kernel has been corrected. Ask for confirmation of its status regarding CVE-2026-98432.
Does Cloudflare protect your website?
The sources reviewed do not establish comprehensive protection against this CVE. Have the kernel checked and, if affected, updated.
Does the vulnerability also affect a static website?
If it is hosted on a vulnerable Linux system with a reachable IPv4 TCP service, the kernel must also be checked there. The content delivered does not determine whether the system is affected.
Does a CVSS 3.1 score of 9.8 prove a breach?
No. The score describes the technical severity under the rating assumptions. Research RCE and possible exploitability do not prove a breach of your server.
Is an installed new kernel automatically active?
No. You must obtain confirmation that it has been activated through the required restart or a loaded live patch demonstrably suitable for this CVE.
Do you have to run server commands yourself?
With shared or managed hosting, send the request to your hosting provider. For self-managed servers, you should ask an administrator to compare the package version, running kernel and vendor advisory.