A flaw in the core of Linux, the operating system that runs most of the world's servers, cloud platforms, and network equipment, can let an attacker on the internet take complete control of a vulnerable machine without a password and without anyone clicking anything. Researchers have already built a working attack that does exactly that. Ubuntu and Red Hat Enterprise Linux, two of the most widely used versions of Linux in business, have not yet released a fix, and neither has given a date.
There are no confirmed attacks in the wild and no public exploit code as of October 30. That is the window to use. Organisations that know which of their Linux systems are exposed to the internet, and which can be patched today, will be in a far better position than those waiting for every vendor to catch up.
The bug is CVE-2026-98432, a race condition in the Linux kernel code that sets up new IPv4 TCP connections. It was quietly fixed upstream on October 5 and published as a CVE on October 15, but drew little attention until October 24, when the kernel's own CVE team scored it 9.8 out of 10. Three days later, Anthropic disclosed that one of its research models had written an exploit that uses the flaw to run commands as root on a remote server. The bug dates back to Linux 4.4, so it is present in almost every enterprise Linux kernel shipped in roughly the last decade.
How the flaw works
The vulnerability is a use-after-free: under the right timing, the kernel reads memory it has already released. It happens during the TCP handshake.
- When a connection completes,
tcp_v4_syn_recv_sock()hands the IP options stored on the pending request (ireq->ireq_opt) to the newly created child socket without copying them. - At the same moment, another CPU can be processing a retransmitted SYN for that same request and building a SYN-ACK reply, reading those same options under only an RCU read lock.
- Since commit
079096f103fa, request sockets are processed without holding the listener lock, so nothing stops the child socket from being destroyed while that SYN-ACK is still being built. The child frees the options with a plainkfree(), andip_options_build()then reads freed memory. - A second, similar path exists when request socket migration is enabled (
net.ipv4.tcp_migrate_req=1, or aBPF_SK_REUSEPORT_SELECT_OR_MIGRATEprogram), where a cloned request socket and the original share the same options.
The fix (upstream commit e3f33b0a1d89, credited to Anthropic researcher Xinyang Ge) changes inet_sock_destruct() and tcp_v4_reqsk_destructor() to use kfree_rcu(), so the memory is only released once every CPU that might be reading it has finished.
IPv6 is not affected by the main issue, because the IPv6 path copies the options rather than handing them over. A related IPv6 migration issue, reachable only when CALIPSO labelling is in use, will be fixed in a separate patch.
Why the scores disagree
Depending on where you look, this flaw is rated anywhere from Moderate to Critical. The spread matters for prioritisation, so it is worth understanding.
| Source | Score | Attack complexity | Notes |
|---|---|---|---|
| Linux kernel CNA | 9.8 Critical (CVSS 3.1) | Low | Added to the CVE record October 24; also shown by NVD |
| Ubuntu | 9.8 Critical; priority High | Low | Uses the kernel CNA score |
| Red Hat | 8.1 Important (CVSS 3.1) | High | Raised from Moderate (5.9) on October 29 |
| SUSE | 8.1 Important (CVSS 3.1); 9.2 (CVSS 4.0) | High | |
| Oracle | 8.1 Important | High | |
| Amazon | 7.0 Important |
The kernel team's 9.8 score is based on a specific attack: the attacker sends a SYN carrying IPv4 Record Route or Timestamp options, then resends it repeatedly to try to win the race. Because the attacker controls both sides of the timing, the team rated attack complexity as low. In that scenario, it says, the bug could leak nearby kernel memory to the attacker, corrupt kernel memory, or crash the system.
The distribution vendors agree on every other metric, including high impact on confidentiality, integrity, and availability, but consider the race hard enough to win that they rate complexity as high. Red Hat's position shifted during the week: its CVE page initially called the issue Moderate and described a crash as the most likely result, before its advisory data and bug tracker raised it to Important on October 29.
Our view is that the vendor scores are defensible in theory, but Anthropic's demonstration showed that a lost race costs the attacker nothing except one failed connection attempt. A hard race that can be retried indefinitely, without crashing the target, is a question of time rather than skill.
The AI-built exploit
Anthropic's Frontier Red Team described the exploit in an October 27 post covering several flaws its unreleased research model found and weaponised. According to Anthropic, the model wrote the Linux exploit after initial prompting from a researcher, as a lab exercise rather than a real-world incident.
The exploit works in two stages:
- Information leak. The race causes the kernel to send extra bytes back in its replies. Once one of those replies contains a kernel address, the attacker can defeat KASLR, the kernel's memory address randomisation.
- Code execution. The same bug then overflows a buffer and overwrites a callback pointer with the address of a payload the attacker has already placed in kernel memory. When the kernel calls that pointer, the payload runs a shell command of the attacker's choosing as root.
In Anthropic's test, the address leak took 48 minutes and command execution took about 5 more. Because a failed attempt only fails that one handshake, the process is quiet and repeatable.
Two caveats are important:
- The exploit targeted servers with a Multipath TCP (MPTCP) listener. Neither the CVE record nor the kernel fix mentions MPTCP; that link comes only from Anthropic's post, which does not say whether servers without an MPTCP listener can be taken over the same way.
- No exploit code, kernel version, or test configuration was published, and no outside team has yet reproduced the full chain.
The MPTCP detail carries more weight than it might first appear. MPTCP lets one connection use several network paths at once, and on Linux an application has to ask for it when it opens a socket. Since Go 1.24, Go programs ask for it by default on the sockets they listen on. A large share of modern infrastructure software, including much of the container and cloud-native ecosystem, is written in Go, so MPTCP listeners may be running on systems whose owners never chose to enable the feature.
At the same time, the Go Security Team has said the underlying bug is not specific to MPTCP and that systems with no MPTCP listeners may be vulnerable to similar attacks, and Red Hat describes the attack surface as any reachable TCP service. Treat MPTCP as the path that has been proven, not the only path that exists.
Patch status by distribution
Status as of October 30, 2026. Vendor pages are changing daily, so confirm against each advisory before acting.
| Distribution | Status | Fixed package or advisory |
|---|---|---|
| Ubuntu 22.04, 24.04, 26.04 LTS and 26.10 | Vulnerable, fix in progress | None released |
| Ubuntu 16.04, 18.04 and 20.04 | Vulnerable | None released |
| Ubuntu cloud (AWS, Azure, GCP, Oracle), FIPS and real-time kernels | Vulnerable or in progress | None released |
| RHEL 8, 9 and 10; OpenShift 4 | Affected | None released; no mitigation meets Red Hat's criteria |
| RHEL 7 | Not affected | Not needed |
| SUSE SLES 16.0, SLES for SAP 16.0, SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Fixed | kernel-default 6.12.0-160000.40.1 or later |
| SUSE SLES 15 SP4, SP5 and SP6 LTSS; SLE Micro 5.3 to 5.5 | Fixed (October 29) | SP4 and Micro 5.3/5.4: 5.14.21-150400.24.246.1; SP5 and Micro 5.5: 5.14.21-150500.55.195.1; SP6: 6.4.0-150600.23.143.1 |
| SUSE SLES 15 SP7 | Affected, fix in progress | None released |
| SUSE Linux Micro 6.0 and 6.1; SLES 12 SP5 | Affected | None released |
Amazon Linux 2023, kernel6.18 |
Fixed October 24 | kernel6.18-6.18.56-125.164.amzn2023 (ALAS2023-2026-3251) |
Amazon Linux 2023, kernel6.12 |
Fixed October 29 | kernel6.12-6.12.113-138.209.amzn2023 (ALAS2023-2026-3335) |
Amazon Linux 2; Amazon Linux 2023 default kernel |
Pending | None released |
| Oracle Linux 7 to 10, UEK | Fixed October 16 | ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399 |
| Debian 13 (trixie) | Fixed October 16 | linux 6.12.113-1 (DSA-6568-1) |
| Debian 12 (bookworm) | Fixed October 17 and 22 | linux 6.1.190-1 (DLA-4841-1); linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) |
For organisations that build their own kernels, the fix is in stable releases 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3. The kernel CVE team recommends moving to the latest stable release rather than cherry-picking the individual patch.
What you should do
1. Patch internet-facing systems first, where a fix exists
If your distribution has shipped a fixed kernel, install it now and work outward from your exposure. Prioritise anything that accepts inbound IPv4 TCP connections from untrusted networks: web servers, API gateways, load balancers, VPN and remote access endpoints, and Kubernetes nodes exposing services.
2. Reboot, and verify the running kernel
A kernel update does nothing until the system restarts, or a livepatch is applied where your vendor offers one. Check the running version with uname -r afterwards; it is common to find hosts where the package was updated but the old kernel is still running.
3. Find your MPTCP listeners
Run ss -Mlnp to list services listening with MPTCP. These match the configuration Anthropic proved exploitable and should be first in line for patching or the interim steps below. Pay particular attention to Go services built with Go 1.24 or later.
4. Reduce exposure while you wait for Ubuntu, RHEL, or another pending fix
No vendor has published a mitigation, and none of the advisories confirms that any workaround closes the risk. The following steps reduce exposure; they do not replace the patch.
- Disable MPTCP where it is not needed. Setting
net.mptcp.enabled=0via sysctl stops new MPTCP sockets being created system-wide. For Go services, the Go Security Team notes thatGODEBUG=multipathtcp=0disables MPTCP at runtime, andgodebug multipathtcp=0ingo.moddoes so at build time, though code that callsSetMultipathTCPoverrides both. The Go team itself calls per-program disabling a fragile mitigation. - Confirm request socket migration is off. Check that
net.ipv4.tcp_migrate_reqis0(the default) unless you have a specific need for it, since it opens the second vulnerable path. - Consider dropping inbound IPv4 packets that carry IP options at the perimeter. The kernel team's attack scenario relies on SYNs carrying Record Route or Timestamp options, which legitimate internet traffic very rarely uses. No vendor has confirmed that this blocks exploitation, but it removes the specific trigger described in the scoring.
- Restrict who can reach listening services. Tighten firewall rules, security groups, and allowlists, especially for administrative and internal services that do not need to face the internet.
5. Don't forget the long tail
Appliances, embedded devices, and vendor-supplied virtual machine images often ship their own Linux kernels. Updating your own servers does not fix those; check each vendor for firmware or image updates.
6. Watch for signs of exploitation
This exploit is designed to be quiet, so detection is difficult, but a few signals are worth monitoring:
- Kernel oops messages, KASAN reports, or unexplained panics referencing
ip_options_build,tcp_v4_syn_recv_sock, ortcp_check_req - A sustained stream of retransmitted SYNs from one source, particularly SYNs carrying IPv4 options, aimed at a single listening service
- Unexplained handshake failures or connection resets on listening ports, which can indicate repeated lost races
- New root-owned processes on an exposed host with no corresponding login, deployment, or scheduled task
A note on the pattern
The most significant part of this story is not the bug itself but how quickly it went from an obscure kernel fix to a demonstrated remote root exploit. The patch landed upstream on October 5 with little fanfare. Twenty-two days later, an AI model had turned it into a working attack, and two of the most widely deployed enterprise distributions still had not shipped a fix.
That gap between a public fix and a usable exploit has historically given defenders weeks or months. It is getting much shorter, and the same capability that found and weaponised this bug is available, in one form or another, to attackers. Patch processes that wait for a vulnerability to "become serious" before acting will increasingly find that, by the time it does, the window has already closed. The organisations best placed for this are the ones that can answer, quickly and accurately, which systems are running which kernel and which of them face the internet.
Summary
| CVE | CVE-2026-98432 |
| Component | Linux kernel IPv4 TCP handshake (tcp_v4_syn_recv_sock, ip_options_build) |
| Type | Race condition leading to use-after-free |
| Severity | 9.8 Critical (kernel CNA, NVD, Ubuntu); 8.1 Important (Red Hat, SUSE, Oracle); 7.0 (Amazon) |
| Introduced | Linux 4.4 |
| Not affected | IPv6 (main issue); RHEL 7 |
| Exploit status | Remote root demonstrated by Anthropic against servers with an MPTCP listener; no public code; not independently reproduced |
| Exploitation in the wild | None reported as of October 29; not in CISA KEV |
| Upstream fix | Commit e3f33b0a1d89; stable 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 |
| Patched | Debian 12 and 13; Oracle Linux UEK; SUSE SLES 16.0, 15 SP4 to SP6 LTSS, SLE Micro 5.3 to 5.5, SL Micro 6.2, openSUSE Leap 16.0; Amazon Linux 2023 kernel6.18 and kernel6.12 |
| Not yet patched | All Ubuntu releases; RHEL 8, 9, 10 and OpenShift 4; SLES 15 SP7; Amazon Linux 2 and AL2023 default kernel |
| Interim steps | Disable MPTCP where unneeded (net.mptcp.enabled=0, GODEBUG=multipathtcp=0); keep tcp_migrate_req=0; consider filtering inbound IPv4 options; restrict exposure |
| Detection | Kernel oops or KASAN reports in the affected functions; bursts of retransmitted SYNs with IP options; unexplained handshake resets; unexpected root processes |
CVE-2026-98432 is a rare combination: a decade-old bug in code every Linux server runs, a demonstrated path to remote root, and major distributions still without a fix. Patch what you can today, find and reduce your MPTCP exposure, and be ready to move the moment Ubuntu and Red Hat ship their kernels.
If you need help identifying which of your Linux systems are exposed, confirming which hosts are actually running a fixed kernel, or putting interim controls in place while you wait on vendor patches, get in touch. With a fix this uneven across distributions, knowing exactly where you stand is half the work.