What happened
Linux kernel developers have fixed a bug in the code that sets up new IPv4 TCP network connections. The flaw is tracked as CVE-2026-98432 and the Linux kernel CVE team published it on October 15, 2026. The fix itself went into the kernel earlier, on October 5, 2026. According to The Hacker News, it was reported by Anthropic researcher Xinyang Ge.
The bug has been in the kernel since Linux 4.4 and, according to The Hacker News, affects Ubuntu, Red Hat Enterprise Linux and other distributions. On October 27, 2026, Anthropic said its AI model Claude wrote a working exploit. With it, an attacker with no credentials could remotely run commands as root on a server that accepts connections over Multipath TCP (MPTCP).
As of October 29, 2026, none of the vendor advisories, the CVE record or Anthropic’s post reports real-world attacks. The flaw is not in the CISA KEV catalog and the European EUVD database (EUVD-2026-102025) lists no exploitation. However, Ubuntu and Red Hat have not yet released a fixed kernel.
Why it is dangerous
This is a use-after-free bug, meaning the kernel uses memory it has already released. It is caused by a race condition while a TCP connection is being set up. Picture a cloakroom where one attendant frees a hook and hangs someone else’s coat on it while a colleague is still handing out items against the old ticket. The kernel similarly hands connection settings to a new socket without copying them, and if that socket is destroyed while another CPU is still reading them, it ends up working with memory that now belongs to something else.
The attack works over the network and needs no login. According to the kernel CVE team, it can leak bits of kernel memory, corrupt kernel memory or crash the system. Anthropic also demonstrated a full root takeover of a server listening over MPTCP: in its test this took about 53 minutes, and failed attempts did not crash the system. The Go Security Team adds that the bug is not specific to MPTCP and systems without it may be vulnerable to similar attacks.
CVSS rates severity on a scale from 0 to 10. The Linux kernel CVE team scored this flaw 9.8 under CVSS 3.1, which is critical. As of October 28, NVD had no score of its own and displayed that same 9.8. Distribution vendors rate it lower. Red Hat gives 5.9 on its CVE page because it considers the race hard to win, but 8.1 in its machine-readable advisory file. Oracle and SUSE give 8.1 because they rate attack complexity as high. Amazon gives 7.0, and Ubuntu assigns High priority.
The US agency CISA maintains the KEV catalog of vulnerabilities known to be exploited, and this one is not listed. EPSS estimates the probability of exploitation in the next 30 days: on October 29, 2026 it was 0.39%, higher than about 33% of other vulnerabilities. Since Anthropic has already shown the attack works, a low number is no reason to delay patching.
Who is affected
The bug is present in the Linux kernel from version 4.4 up to the fixed releases. That covers common server distributions: Ubuntu, Red Hat Enterprise Linux 8, 9 and 10 including OpenShift 4, Debian, SUSE, Oracle Linux and Amazon Linux. Typical systems are web and application servers, VPS and cloud instances, as well as containers, which share the host’s kernel.
Internet-facing servers carry the highest risk, especially if a service on them listens over MPTCP. The Go Security Team points out that since Go 1.24, Go programs enable MPTCP by default for listening sockets on Linux.
RHEL 7 is not affected, according to Red Hat. The described race does not affect IPv6 connections, because the kernel copies the settings for them. If you run Linux-based devices such as a NAS or network appliances, check with their vendor whether a fix is available.
How to check if you are affected
First find out which distribution and kernel the server is running. These commands change nothing, they only read:
cat /etc/os-release
uname -rCompare the version from uname -r with the fixed versions in the next section. Note that a new kernel is only used after a reboot, and uname -r always shows the kernel currently running. To list installed kernel packages:
dpkg -l 'linux-image*' # Debian, Ubuntu
rpm -qa 'kernel*' # RHEL, Oracle Linux, SUSE, Amazon LinuxTo see whether any service listens over MPTCP, and which Go version a program was built with (if you have the Go tools installed):
ss -lM
go version /path/to/programHow to fix it
The main fix is to install a patched kernel, which the Go Security Team also strongly recommends. The fix is in kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. If you build your own kernel, the kernel CVE team recommends moving to the latest stable kernel and does not support cherry-picking individual fixes. Fixed distribution packages as of October 29, 2026:
- Debian trixie:
linux6.12.113-1 (DSA-6568-1) - Debian 12 bookworm:
linux6.1.190-1 (DLA-4841-1) orlinux-6.126.12.113-1~deb12u1 (DLA-4850-1) - Oracle Linux 7, 8, 9 and 10 with the UEK kernel: ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399
- SUSE Linux Micro 6.2 and openSUSE Leap 16.0:
kernel-default6.12.0-160000.40.1 or later - Amazon Linux 2023: kernel6.18-6.18.56-125.164.amzn2023 (ALAS2023-2026-3251), kernel6.12-6.12.113-138.209.amzn2023 (ALAS2023-2026-3335)
No fix is available yet for Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04, 26.04 and 26.10, RHEL 8, 9 and 10, OpenShift 4, Amazon Linux 2, the kernel package in Amazon Linux 2023, SLES 15 SP4 to SP6 LTSS and SP7, SLES 16.0 and SLE Micro 5.3 to 5.5. Proceed as follows:
- List your Linux servers and start with internet-facing ones and those running services over MPTCP.
- Where a fix exists, install it with a normal update and reboot. Then confirm with
uname -r. - Where there is no fix yet, watch your vendor’s advisories and update as soon as it is released.
Red Hat says no mitigation meets its standards, and the other vendors list none. The Go Security Team explains how to disable MPTCP in Go programs, but calls this a fragile mitigation. The setting does not apply to sockets where the program explicitly enables MPTCP via SetMultipathTCP:
GODEBUG=multipathtcp=0 # program environment variable
godebug multipathtcp=0 # line in the main module's go.modNeither the vendors nor Anthropic say whether disabling MPTCP system-wide or blocking packets with IP options reduces the risk. At a minimum, use a firewall to restrict access to services that do not need to be public.
What if you may already be compromised
As of October 29, 2026, neither the vendors, the CVE record nor Anthropic report attacks using this flaw, and none of them lists specific indicators of compromise. Any check can therefore only be general:
- The kernel log: unexpected reboots and messages such as “kernel oops” or “panic”. Red Hat names a kernel crash as the most likely outcome.
- Unknown processes running as root, new user accounts, new SSH keys in
authorized_keysand newcronjobs. - Unusual outbound connections from the server.
dmesg and journalctl -k only show the current boot. journalctl -k -b -1 shows the previous boot, but only if the journal is stored persistently. A hard crash may also leave no message behind.
journalctl --list-boots
journalctl -k -b -1 | grep -iE 'oops|panic|BUG:|general protection'
dmesg -T | grep -iE 'oops|panic|BUG:|general protection'The absence of crashes proves nothing, because according to Anthropic a failed attempt does not bring the system down. If you find anything suspicious, disconnect the server from the network, delete nothing and call in an incident response specialist. An attacker with root access can hide their tracks, so after a confirmed breach reinstalling the server is recommended.