Linux Kernel Vulnerability Allows Attacks via Incoming TCP Connections
A critical Linux kernel flaw allows attackers to target servers through incoming TCP connections without a password. Server owners should check their distribution’s patch status and install the update.
Linux kernel developers released fixes on October 11 and 15 for CVE-2026-98432, a flaw that allows attackers to target a server over the network without a password or any action by its owner. As Tproger reports, the vulnerability affects the handling of incoming TCP connections over IPv4 and has been present in the kernel since version 4.4. The kernel team rated its severity at 9.8 on the CVSS scale. As of November 1, fixes were not yet available for Ubuntu or RHEL. Server owners should check the patch status for their distribution and the version of the running kernel; if a fix is available, they should install it and reboot the machine.
Why the flaw can be triggered before a password is checked
When a TCP connection is established, the kernel may retain options from the IPv4 packet header for use in its response. In the vulnerable code, this data is passed to a new connection without being copied. If the connection closes quickly, the memory is freed even though another CPU core may still be reading it while handling a subsequent connection request.
This is a use-after-free flaw: a region of memory has already been made available for other data, but the code continues to use it. According to the CVE record, an attacker may be able to leak a fragment of kernel memory, write beyond a buffer, or crash the system. This processing happens before the request reaches a web server, SSH, or a database. A strong password and application settings alone therefore offer no protection against it.
The fix replaces immediate memory deallocation with a mechanism that waits until the data is no longer being read. Fixed kernel versions have been identified for supported Linux branches, including 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, and 6.18.56. But distributions backport patches into their own builds: the kernel version number alone is not a reliable answer without checking the distribution’s information.
On October 27, Anthropic said Claude had produced a working exploit: in the company’s test, it remotely executed commands as root on a server with an open Multipath TCP (MPTCP) port. The attack took about 53 minutes. The company did not publish the code; as of November 1, this CVE was not in the CISA KEV catalog, which lists vulnerabilities known to be exploited in real-world attacks. Its absence from the catalog does not negate the demonstrated exploitability.
What website owners and administrators should check
The immediate concern is for anyone whose Linux servers accept incoming TCP connections over IPv4: VPS instances, hosts running websites and databases, and Kubernetes nodes. A container uses the host kernel, so updating a Docker image will not solve the problem. With container-based VPS virtualization, the kernel may be managed by the provider, in which case the update depends on them.
As of November 1, fixes were already available for Debian, Amazon Linux, and Oracle Linux; SUSE’s status depended on the version and kernel. Patches for Ubuntu and RHEL 8, 9, and 10 were still in progress. Check the status of your specific distribution and the running kernel with uname -r. If a fixed kernel has been installed but the server has not been rebooted, it is not yet protecting the system. The exception is live patching, where it is available for the particular configuration.
Until an update is available, Red Hat and AlmaLinux suggest reducing the risk with an nftables rule that drops incoming TCP packets with options in the IPv4 header. Test it on a test machine before applying it: the rule may affect routed traffic and is incompatible with networks that use IPv4 options for CIPSO labels. It also does not replace a fixed kernel. AlmaLinux’s version runs at the prerouting stage and also covers traffic to containers; Red Hat’s rule runs at the input stage and protects only the host itself.
Another temporary measure is to disable MPTCP if it is not needed. According to the Go team, starting with Go 1.24, programs on Linux open listening sockets with MPTCP by default. You can check open ports with ss -Mlnp and the mechanism’s current status with sysctl net.mptcp.enabled. After disabling it, services with MPTCP sockets already open must be restarted; the setting should be checked separately in individual container network namespaces. Importantly, the exploit demonstrated by Anthropic required MPTCP, but the kernel flaw itself is not limited to it.
My view: temporary protection should not become permanent
I would start by listing the hosts that accept external connections and checking which kernel is actually running on each one. A Kubernetes node or a VPS whose kernel updates are not controlled by the website team is particularly easy to miss. For a business, this is one of those cases where updates are not just a developer concern: rebooting a production server needs to be scheduled too.
Disabling MPTCP and filtering packets seem like sensible interim steps where a patch is not yet available. But I would not mark the task complete after configuring nftables: temporary measures have limitations, and the vulnerable code remains in the kernel. The final check is that the fix has been installed and the server is running the updated kernel.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
Full-Stack Developer
I build websites and internal tools for small teams in Poland. I like it when you can replace a CMS without rewriting all the business logic.
All posts by the authorRelated articles
PHP Core Vulnerabilities Patched That Could Allow Remote Code Execution
PHP has patched core vulnerabilities that could lead to remote code execution and process memory disclosure. Website owners should check their PHP version and install the security update.
ISPsystem Releases VMmanager Updates After Zero-Day Attack
ISPsystem has released security updates for VMmanager and reworked its security architecture after a zero-day attack. Checks of providers’ infrastructure are ongoing.
PHP Releases Four Updates to Fix Two Critical Vulnerabilities
PHP has released four updates to fix two critical vulnerabilities. Under certain conditions, an attacker could execute code on a server. Site owners and developers are advised to update PHP.
Discussion 5
Rūta S.
Since the flaw has reportedly been in the kernel since 4.4, how can admins verify whether a distribution has backported the fix when the running kernel’s version number hasn’t changed much?
Michał Kowalski Post author
@ruta_sakala, check the distribution’s advisory and the installed kernel package’s full release/build string, not just `uname -r`’s upstream version. Distros often backport fixes while keeping that base version, so look for the CVE in the package changelog or advisory and confirm the patched package is installed; then reboot so the running kernel actually picks it up.
Oliver Lopes
The package changelog is the kernel’s little alibi: useful, but I’d still want the patched build installed and the machine rebooted before calling the case closed.
Eero Laine
Do Ubuntu and RHEL have an estimated timeline for patches, or is the practical advice for now to use a temporary mitigation and keep checking? I’m still learning the kernel-update dance, and “just reboot after patching” sounds easy right up until the patch hasn’t landed yet.
Michał Kowalski Post author
The post doesn’t give an ETA from either distro, so I’d treat their security advisories as the source of truth rather than assume a date. Until a patched kernel is available, keep checking for updates and follow any mitigation your distro explicitly recommends; once it lands, install it and reboot so the running kernel actually changes. You’re right that “reboot after patching” only helps after the patch exists.