CVE-2026-98432: the Linux kernel TCP flaw an AI model turned into a remote root exploit

A network flaw in the kernel, then an exploit written by an AI

On 15 October 2026, the Linux kernel CVE team published CVE-2026-98432. It is a use-after-free in how the kernel handles incoming IPv4 TCP connections, scored 9.8 out of 10: reachable over the network, no authentication, no user interaction.

The faulty code dates back to Linux 4.4, released in January 2016. Almost every production kernel is affected, from the long-term branches of RHEL and Debian to recent 7.x releases.

For two weeks it was treated as one more critical kernel CVE. On 27 October, Anthropic published a write-up that changes how the risk should be read: an unreleased Claude research model wrote an exploit that gets a root shell on a remote server in about 53 minutes. It took 48 minutes to leak a kernel pointer, then five more to run commands.

The facts

Vendors disagree on severity:

• 9.8 from the kernel CNA, which treats it as remote code execution;
• 5.9 on the first version of Red Hat's page, which saw a denial of service behind a hard-to-win race, before moving to 9.8 and Critical;
• 8.1 from SUSE, which rates the attack complexity as high (AC:H).

The "hard to win" argument doesn't hold up well, as we explain further down.

One point to keep in mind right away: the bug is in ordinary IPv4 TCP. MPTCP only appears in the published root exploit. Red Hat says it plainly: RHEL, "which disables MPTCP in its default configuration, is still vulnerable".

Patch status by distribution (5 November 2026)

This table changes daily. Check your vendor's tracker before acting.

And keep in mind that a fixed kernel only protects you after a reboot.

Ubuntu, still waiting

• Every kernel is marked "work in progress", cloud flavours included (linux-aws, linux-azure, linux-gcp).
• The priority moved to Critical on 4 November, but no fixed package has shipped.
• If you expose services on Ubuntu, the network filter described below is your main protection today.

Proxmox VE, fixed by way of Ubuntu's source

The Proxmox kernel is built on Ubuntu's. The fix arrived with Ubuntu's 7.0.0-43 source, and Proxmox shipped it in 7.0.14-25-pve and then -26, now on the enterprise repository too.

A Proxmox developer confirmed on the forum that the fixing commit is included. Ubuntu's own security tracker hasn't caught up with its source tree yet, which explains the gap between the two.

For Proxmox VE 8, we found no confirmation.

How the flaw works

You don't need to read kernel C to follow the principle. Here is what normally happens on a connection:

1. A client opens a TCP connection, and its SYN carries IPv4 options.
2. The kernel keeps those options on the pending request socket, so it can echo them in the SYN-ACK.
3. At the end of the handshake, tcp_v4_syn_recv_sock() creates the real socket and hands it the options buffer by pointer, without copying it.

That is fine as long as nobody else is still reading the old buffer. But since a 2015 change, SYN-RECV requests can be processed without the listener lock.

So a second CPU can handle a retransmitted SYN for the same request at the same moment. It reads the options under a simple RCU read lock to build its own SYN-ACK. If the child socket is torn down in the meantime, and its options freed with kfree(), that CPU reads memory that already belongs to something else.

A second path leads to the same result: request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF reuseport program). That setting is off by default. For most servers, the retransmitted SYN is the path that counts.

The fix is short. In two destructors, kfree() becomes kfree_rcu(), which waits for an RCU grace period before releasing the memory. The other code paths handling these options already worked that way.

IPv6 escapes the main issue, because tcp_v6_syn_recv_sock() copies the options instead of handing them over.

Anthropic's exploit: what has been demonstrated

On 27 October, Anthropic reported that an unreleased Claude research model had written a full remote exploit for this bug, "after initial prompting".

We treat that claim with the usual caution, since neither the code nor the test configuration has been published. Two things still make it credible:

• the chain they describe is consistent with the fixing commit;
• that commit's Reported-by names an Anthropic researcher, who knew this code well before publication.

53 minutes on one side, 43 days on the other

Verizon's 2026 Data Breach Investigations Report gives two useful reference points for that number:

• the median time to remediate a vulnerability from CISA's KEV catalog is now 43 days, up from 32 a year earlier;
• 31% of initial access now starts with an exploited vulnerability.

Under an hour of compute to reach root, six weeks of median delay to patch. Speeding up manual patching won't close that gap on its own.

Who is exposed?

The kernel number matters less than one simple question: do you expose a TCP service over IPv4 on an unpatched kernel?

Almost every server does. So the triage is about exposure:

• A Linux server reachable from the Internet (web, API, SSH, mail, load balancer): exposed. This is the most common case, and the most urgent.
• Go services built with Go 1.24 or later: look at these first. Since Go 1.24, the standard library enables Multipath TCP by default on listening sockets on Linux. That is exactly the configuration Anthropic's exploit targets, and few teams chose it knowingly.
• RHEL and its rebuilds, where MPTCP is off: the published exploit doesn't apply as written, but the flaw is there. Red Hat says so, and the patch is still critical.
• IPv6: the main bug only affects IPv4. A dual-stack server still answers on IPv4, so it remains exposed.

What about the cloud?

It is usually the first question in the meeting. AWS's bulletin 2026-160 shows the split of responsibilities well:

• AWS has patched its own front-end services (ALB, NLB TLS, CloudFront, API Gateway, WAF);
• Lambda is out of scope;
• fixed kernels exist for Amazon Linux 2 and 2023;
• the EC2 and Lightsail instances you manage are your responsibility: kernel update, then reboot, which AWS calls "the only complete remediation".

GameLift Streams and Cloud9 Ubuntu environments are waiting on Canonical, like everyone else.

Checking your servers without breaking anything

Don't try to reproduce the flaw on your own machines. The race can crash the host, and there is no harmless payload to send.

Verification happens on the host itself, based on version and configuration.

1. The kernel actually running

uname -r

2. Multipath TCP listeners

This is the configuration behind the only published root exploit. It is often enabled without anyone having decided it.

sysctl net.mptcp.enabled       # 1 = MPTCP sockets can be created
ss -lnMp                        # processes holding MPTCP listeners

If ss -lnMp shows listeners nobody expected, those are your priority targets.

For Go binaries, there are two options that don't touch the kernel:

• GODEBUG=multipathtcp=0 in the service environment;
• a godebug multipathtcp=0 line in the main module's go.mod, followed by a rebuild.

The Go security team itself calls this "a fragile mitigation". One forgotten listener is enough to reopen the door, and nothing guarantees that every viable exploit goes through MPTCP. Their first recommendation is still the patched kernel. So is ours.

3. From the outside, not much

An external scan cannot tell you whether a host is vulnerable to CVE-2026-98432, because the kernel version isn't visible remotely.

You can sometimes tell whether a port accepts MPTCP, by offering the MP_CAPABLE option in a SYN and checking whether it comes back in the SYN-ACK. That tells you about the protocol, not about the kernel's patch level.

The outside view is useful for something else: knowing which hosts expose a TCP service, and spotting new ones as they appear.

Fixing it, and holding on until you can

The measures, from most to least effective:

1. Install the fixed kernel and reboot. It is the only complete fix. On hosts other services depend on, drain or migrate the workload first, since the reboot drops every connection.
2. Add a network filter until you can reboot. It drops inbound TCP packets carrying IP options. Red Hat, AlmaLinux, CIQ and Ubuntu all recommend it. Here is the nftables version from AlmaLinux's advisory:

   sudo nft -f - <<'EOF'
   add table ip cve_2026_98432
   delete table ip cve_2026_98432
   table ip cve_2026_98432 {
       chain prerouting {
           type filter hook prerouting priority -300; policy accept;
           meta l4proto tcp ip hdrlength > 5 counter drop
       }
   }
   EOF

   To check it: sudo nft list table ip cve_2026_98432. To remove it once the fixed kernel is running: sudo nft delete table ip cve_2026_98432.
3. Turn off MPTCP where you don't need it. sysctl -w net.mptcp.enabled=0, persisted in /etc/sysctl.d/, plus GODEBUG=multipathtcp=0 for Go services. Existing MPTCP listeners survive the change, so restart the services that hold them. This closes the demonstrated exploit, not the flaw.
4. Use livepatching, if you have it. KernelCare, SUSE Live Patching and similar services sometimes offer a rebootless patch for your exact kernel. Treat it as a bridge to the real reboot.

The limits of the nftables filter

The filter helps, but its side effects rarely make it into advisories. We list them because "temporary" rules tend to stay in place long after the incident.

• It doesn't survive a reboot. A host rebooted without the new kernel (power cut, unrelated maintenance) comes back unprotected. Persist the rule, or make the kernel update and the reboot a single operation.
• It filters forwarded traffic too. On a VPN gateway, a hypervisor bridging VMs or a Kubernetes node, packets with IP options passing through the machine are dropped as well. That is usually what you want, but note it in the change ticket.
• It blocks CIPSO. Networks using CIPSO labels (NetLabel, some multi-level security environments) carry them in IPv4 options.
• It doesn't cover traffic between containers on the same host. Those packets never go through the prerouting hook. Red Hat confirms it for OpenShift: there is no mitigation yet for pod-to-pod traffic.
• It affects very little legitimate traffic. IP options are rare on the Internet, and routers often strip them already. The rule's counter lets you check before removing it.

What to watch

No detection signature has been published. On exposed, unpatched hosts, watch for:

• kernel oopses or panics that coincide with inbound connections;
• unusual volumes of IPv4 packets carrying IP options;
• the nftables rule counter going up.

None of these proves an attack. Together, on an unpatched host, they justify isolating it.

If you suspect a successful exploit, treat the whole host as compromised. An attacker with root in the kernel has access to everything the machine knows, including secrets and access to other systems.

What this flaw changes for security teams

Until now, the usual reasoning about a disclosed kernel race went like this: critical on paper, hard to exploit in practice, so it can wait for the next patch cycle.

CVE-2026-98432 contradicts that reasoning. The bug is ten years old and subtle, and a model still turned it into remote root in under an hour.

We don't think this calls for panic. But the delay between disclosure and exploitation, which let teams patch at their usual pace, can no longer be taken for granted.

With this kind of flaw, what matters is very concrete:

• knowing which hosts are reachable from the Internet;
• knowing which kernel each one actually runs;
• finding Go services that opened an MPTCP listener without anyone noticing;
• catching the host that came back from a migration with last quarter's kernel.

An annual pentest answers none of these questions. You need to map your information system and inventory your external attack surface, and do it continuously.

If attackers use AI to exploit faster, defenders have every reason to use it to test their own perimeter too. We explain how an AI pentest agent works in a separate article. The PwnEscape VM escape, two weeks earlier, raised the same question.

What Flawfence can see, and what it can't

Flawfence does not fire kernel exploits at your servers, and does not claim to confirm CVE-2026-98432 remotely. The kernel version isn't visible from outside, and sending the real trigger could crash the host. Be wary of any offer that promises otherwise.

Our work covers the other part of the problem: exposure. Flawfence:

• maps your Internet-facing perimeter;
• lists the services answering in your name;
• places their observable versions in known vulnerable ranges, where possible;
• alerts you when a new host, a forgotten console or a service that came back after a migration shows up, without waiting for the next audit.

Frequently asked questions about CVE-2026-98432

What is CVE-2026-98432?

A use-after-free in the Linux kernel's IPv4 TCP connection handling, scored 9.8 on CVSS. A remote, unauthenticated attacker can reach it through any exposed TCP port.

An unreleased Claude model built a proof of concept from it that reaches a root shell in about 53 minutes, against a server with a Multipath TCP listener.

Is it exploitable remotely from the Internet?

Yes. Unlike many kernel bugs, this one is triggered by ordinary IPv4 TCP packets sent to a listening port, with no authentication and no interaction. Hence the AV:N vector and the 9.8 score.

Do I need Multipath TCP to be vulnerable?

No. The only published root exploit targets an MPTCP listener, but the bug is in plain IPv4 TCP. Red Hat states that RHEL, which disables MPTCP by default, remains vulnerable.

Disabling MPTCP closes one demonstrated exploit path, not the vulnerability.

Is Ubuntu patched?

Not as of 5 November 2026. The priority moved to Critical on 4 November, but every kernel (22.04, 24.04, 26.04, 26.10, cloud flavours included) is still marked "work in progress".

In the meantime, apply the nftables filter that drops IPv4 TCP packets carrying IP options, and disable MPTCP where you don't use it.

Which kernel version fixes CVE-2026-98432?

Upstream: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.

Distributions backport the fix under their own numbering, for example kernel-5.14.0-687.64.1.el9_8 for RHEL and AlmaLinux 9, 6.1.190-1 for Debian 12 and 7.0.14-25-pve for Proxmox VE 9. The table above lists the others.

Why does Go matter here?

Since Go 1.24, the standard library enables Multipath TCP by default on listening sockets. Many Go services therefore expose the configuration the published exploit targets, without anyone having chosen it.

GODEBUG=multipathtcp=0, or a godebug multipathtcp=0 line in go.mod, turns it off. The Go team itself calls that a fragile mitigation.

Is it being exploited in the wild?

Not to our knowledge as of 5 November 2026. No public code achieves code execution, no exploitation has been reported, and the flaw is not in CISA's KEV catalog. Anthropic's exploit was demonstrated in a lab and its code has not been released.

Does init_on_free=1 protect me?

No. It zeroes memory when it is freed, while the leak reads memory that is still in use. A CIQ kernel engineer showed this on the oss-security list. The real protections are the network filter and the fixed kernel.

Sources

• NVD, CVE-2026-98432
• Kernel commit e3f33b0a1d89, "ipv4: free inet_opt and ireq_opt after an RCU grace period"
• Anthropic, "Discovering vulnerabilities with Claude"
• Red Hat, RHSB-2026-016 and CVE page
• AlmaLinux, CVE-2026-98432 advisory
• Ubuntu Security, CVE-2026-98432
• Debian Security Tracker, CVE-2026-98432
• SUSE, CVE-2026-98432
• AWS, security bulletin 2026-160
• Proxmox forum, "CVE-2026-98432 in Proxmox VE"
• Go security team, "Protecting against CVE-2026-98432 when using Go programs" (oss-security)
• oss-security, Sultan Alsawaf (CIQ) on init_on_free=1
• BleepingComputer, "Critical Linux kernel flaw allows remote root attacks on MPTCP servers"
• Verizon 2026 Data Breach Investigations Report