CVE-2026-98432: the Linux kernel TCP flaw and how to check your server

What is CVE-2026-98432?

CVE-2026-98432 is a critical Linux kernel vulnerability: a use-after-free in how the kernel handles the IPv4 TCP handshake when a connection request carries IP options. The kernel CNA scores it 9.8 (Critical), and an attacker needs no login. Anyone running a Linux server or VPS with a public IPv4 port should check it. Short on time? Jump to the checklist.

In plain words, as AlmaLinux explains it: when a connection request (a SYN packet) carries IPv4 options, the kernel keeps them to echo in its reply. When the handshake completes, the options are handed to the new socket without a copy. If the client retransmits its SYN, another CPU can be building a reply from those options while the new connection is closed and freed. The reply code then reads freed memory.

The fix, authored on 1 October 2026 by Eric Dumazet, is titled "ipv4: free inet_opt and ireq_opt after an RCU grace period". It changes kfree() to kfree_rcu() in two places (kernel CVE record). The bug is not new: it came in with an October 2015 commit and first shipped in Linux 4.4, released in January 2016.

CVE-2026-98432 at a glance

CVE-2026-98432 is a critical (CVSS 9.8) use-after-free in the Linux kernel IPv4 TCP handshake. It can be reached remotely without a login and affects kernels from 4.4 on. As of 2 November 2026, no exploit is public and no attacks in the wild are reported, but Ubuntu and RHEL still lack fixed kernels.

Distribution kernels use their own version numbers, so compare your uname -r against your vendor's advisory, not against the upstream list.

Is my Linux server or VPS vulnerable to CVE-2026-98432?

A Linux server or VPS is vulnerable by CVE-2026-98432 if it runs a vulnerable kernel from 4.4 onward and has an IPv4 TCP listener that untrusted networks can reach. Red Hat says the flaw "affects any system running a vulnerable kernel version with IPv4 TCP networking enabled" and that systems accepting inbound TCP connections are most directly exposed (RHSB-2026-016).

• IPv6. The main flaw does not affect IPv6, because the kernel duplicates the options there. A related IPv6 issue exists only with CALIPSO, and the kernel developers will address it in a separate patch.
• KVM or cloud VM. A VPS with its own kernel, such as KVM or an EC2 instance, is yours to patch. AWS: "Customers running self-managed Linux instances on Amazon EC2 are responsible for updating the kernel."
• Container-based VPS and Docker. Containers share the host kernel, so the host operator must patch. You cannot fix the kernel from inside a container. Ask your provider whether and when the host was updated.
• Behind a load balancer. Per AWS, proxies that terminate TCP, such as ALB, CloudFront and API Gateway, do not pass IP options on, and AWS is patching that infrastructure. A Network Load Balancer with TCP listeners and Global Accelerator do pass them to targets, so patch those targets. AWS still recommends updating instances behind ALB and CloudFront within 30 days. A server whose own IP still accepts direct connections stays exposed.
• Firewalls. Ordinary port rules in a host firewall such as ufw do not help for ports that must stay open, because the bug triggers during the handshake on any reachable listening port. Only a rule that drops IPv4 TCP packets carrying IP options (step 3 below) narrows exposure, and only partly.

Is there a patch for CVE-2026-98432 on Ubuntu, RHEL and Debian?

As of 2 November 2026, fixed kernels for CVE-2026-98432 exist for Debian, AlmaLinux, Amazon Linux and parts of CloudLinux and SUSE. Ubuntu and RHEL have none yet. Versions below come from each vendor's own page, linked per row; check it again before you act, because vendor status can change at any time. For Oracle Linux and other distributions, check the vendor's own advisory.

What should you do about CVE-2026-98432 now?

The only complete fix for CVE-2026-98432 is a patched kernel that the server has rebooted into. Everything else on this list buys time until your distribution ships one. The steps are ordered by how much they reduce risk. Where no fixed kernel exists yet, as on Ubuntu and RHEL, steps 3 to 5 are the interim layers.

1. Check which kernel is running.

   • Run uname -r and compare it with the fixed version in your vendor's advisory, linked in the table above.
   • Package managers can show an installed kernel that is not the running one, so trust uname -r.

   uname -r
   

2. Install the fixed kernel and reboot.

   • Update through your package manager, reboot, and run uname -r again to confirm the new version. AWS states that "A kernel update and reboot is the only complete remediation."
   • Live patching is an option on some systems: CloudLinux, which sells KernelCare, says the KernelCare livepatch is on the main feed for CloudLinux 7h, 8 and 9 and on the testing feed for CloudLinux 10. For other live-patch services, check the vendor's note for this CVE.

3. No fixed kernel yet (Ubuntu, RHEL): consider Red Hat's nftables rule.

   • Red Hat publishes this rule for RHEL. It is a generic nftables rule, so it also works on other distributions where nftables is available, but Canonical has not published it for Ubuntu. The rule drops inbound IPv4 TCP packets that carry IP options. Save it as cve-2026-98432.nft:

   table inet cve_2026_98432 {
     chain input {
       type filter hook input priority -310; policy accept;
       ip protocol tcp ip hdrlength > 5 counter drop
     }
   }
   

   • Check, apply and list it, then remove it after patching:

   sudo nft --check --file cve-2026-98432.nft
   sudo nft --file cve-2026-98432.nft
   sudo nft list table inet cve_2026_98432
   sudo nft delete table inet cve_2026_98432
   

   • Limits, in Red Hat's words: it "reduces exposure to this vulnerability but cannot fully prevent it" and is not a substitute for patching. Standard TCP options sit in the TCP header, so ordinary traffic should be unaffected, but test it first. A participant on the oss-security list notes that the filter can be bypassed by traffic between containers on the same host.

4. Disable MPTCP as an extra layer, never as the fix.

   • Check the current setting with sysctl net.mptcp.enabled; 0 means off. AlmaLinux ships with it off.
   • System-wide: sudo sysctl -w net.mptcp.enabled=0, and to keep it after a reboot, echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf (AlmaLinux). A reply on the oss-security list notes that running Go programs may see errors on new connections.
   • Since Go 1.24, Go programs enable MPTCP for listen sockets on Linux by default. Set GODEBUG=multipathtcp=0 at run time or godebug multipathtcp=0 in go.mod at build time (Go GODEBUG documentation). The Go team calls "disabling MPTCP on a program-by-program basis" a "fragile mitigation" and says "The best fix for this vulnerability is to upgrade to a patched kernel version" (oss-security).

5. Close what you do not need.

   • Shut every port that has no reason to be public. Put SSH and admin panels behind a VPN or a private network.
   • The public web or service port still needs the patch.

6. Optional: boot with init_on_free=1.

   • A participant on the oss-security list, not a vendor, suggested it (post). It narrows information leaks and does not fix the bug. Expect a performance cost of about 1 to 5 percent.

7. If a server was exposed before patching and shows crashes or odd behavior, treat it as an incident.

   • Rotate the keys and credentials stored on it: SSH keys, API keys, database passwords, service tokens.
   • Check logins and outbound connections from the time before the patch.

How did Anthropic's Linux remote root exploit work?

Anthropic's remote root exploit for CVE-2026-98432 was written by an unreleased internal research model and works against Linux servers with a Multipath TCP listener. Anthropic's Frontier Red Team published the account on 27 October 2026. The exploit code, the kernel version and the test setup are not public. Anthropic's post does not name the CVE; the Go team and AlmaLinux tie its example to this flaw.

Anthropic wrote: "After initial prompting, Claude wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root, without any credentials or user interaction" (Anthropic).

The exploit has two stages. First it bypasses kernel address randomization (KASLR) remotely, using an over-read that sends kernel bytes back to the attacker. Second, it overflows a buffer to overwrite a callback pointer, with the payload staged in kernel memory "via an ordinary protocol feature". Retrying is cheap: "a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed." In the proof of concept, "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution."

Others are more cautious. CloudLinux says exploiting it "means winning a timing race inside the kernel, which is hard to do", that its team "couldn't reproduce that claim" and that no exploitation in the wild has been reported. AWS says "Researchers have demonstrated unauthenticated remote code execution against hosts with a Multipath TCP (MPTCP) listener" and that it is not aware of exploitation in the wild. Red Hat adds that exploitation "requires precise timing of network requests but does not require any privileges or user interaction."

When was CVE-2026-98432 found, fixed and disclosed?

CVE-2026-98432 entered Linux with a 2015 commit and shipped in kernel 4.4 in January 2016. The CVE ID was reserved on 25 September 2026, the fix was written on 1 October and the record was published on 15 October. Distribution kernels began arriving on 30 October. All times are UTC.

• October 2015. Commit 079096f103fa, "tcp/dccp: install syn_recv requests into ehash table", introduces the flaw.
• January 2016. Linux 4.4 ships the commit, the first affected release.
• 25 September 2026. The CVE ID is reserved.
• 1 October 2026. Eric Dumazet authors the fix, commit e3f33b0a1d89, later in Linux 7.3-rc7.
• 15 October 2026, 12:08. The kernel CNA publishes the CVE record.
• 27 October 2026. Anthropic publishes its research post.
• 29 October 2026, 23:34. The Go team's advisory reaches oss-security.
• 30 October 2026. Red Hat publishes RHSB-2026-016, AlmaLinux ships testing kernels, and Ubuntu updates its CVE page.
• 31 October 2026, 05:15. AWS publishes security bulletin 2026-160-aws. The same day, the init_on_free post appears on oss-security.
• 1 November 2026, 17:00. AWS Fargate's patched platform begins serving new tasks.
• 2 November 2026. AlmaLinux fixed kernels reach production repositories. Ubuntu and RHEL still have no fixed kernel.

What do people get wrong about CVE-2026-98432?

Most confusion about CVE-2026-98432 comes from posts that mix up Anthropic's demonstration with the bug itself. The bug is in ordinary IPv4 TCP, the 53 minutes are attack runtime, and no exploit is public. The claims below circulated on X and in news coverage, each checked against the primary sources.

• Claim: "Only MPTCP servers are affected, so turning MPTCP off fixes it." The Go team, AlmaLinux, CloudLinux and Red Hat say the bug is in ordinary IPv4 TCP. CloudLinux notes that on its systems MPTCP is off by default and "those servers still need the fix."
• Claim: "The AI wrote a root exploit in 53 minutes." Fifty-three minutes is 48 plus 5 minutes of attack runtime in Anthropic's proof of concept. Anthropic does not say how long writing took.
• Claim: "The exploit is public and attacks are underway." The exploit is not public, and AWS and CloudLinux know of no exploitation in the wild as of 2 November.
• Claim: "It is a brand-new bug." The flaw comes from a 2015 commit and has shipped since Linux 4.4.
• Claim: "An apt or dnf upgrade is enough." The kernel only changes after a reboot. Check uname -r.
• Claim: "Red Hat rates it 8.1, so it is not critical." Red Hat shows 9.8 Critical as of 2 November. SUSE is the vendor at 8.1.
• Claim: "Claude, the public product, found it." Anthropic says an unreleased internal research model did.

Open questions: whether any exploit exists that works without an MPTCP listener (the Go team says systems without MPTCP listeners may be open to similar attacks, though none has been shown), and when Ubuntu and Red Hat will ship fixed kernels.

What does CVE-2026-98432 mean for security and leadership teams?

For security and leadership teams, CVE-2026-98432 shows that patch speed depended on the distribution and on who owns the kernel. Debian and AlmaLinux users had fixed kernels by 2 November, Ubuntu and RHEL users were waiting, and container tenants waited on their host operator. Knowing which of these you run is part of the answer.

A server taken over before it was patched exposes what is on it: customer databases, credentials, API keys and SSH keys. Stolen data and server access get sold. Access sellers are known as initial access brokers, and their listings appear on dark web forums and marketplaces. EDG3 is WebThreat's threat intelligence for stolen data posted and sold on dark web forums, marketplaces, Telegram and other channels, and leak databases. For a domain you have authorized, it shows what was posted, where and by whom.

Servers are also reached through people: admin and hosting-panel logins held by your staff are a second way in. CEM finds your executives from your company name and checks their current and past email addresses against breach corpora and leak databases, ranked by what to fix first. It starts with the leadership team and can extend to employees.

Related October reading: the php2shell flaws in PHP servers, and the supplier and credential compromises in Black October.

How WebThreat can help

WebThreat does not scan servers, kernels or open ports, and it does not patch them. That belongs to your ops team, your hosting provider or your Linux vendor. Our part starts if something has gone wrong and data is out.

• EDG3 shows what has been posted about your authorized domain on dark web forums, marketplaces, Telegram and other channels, and in leak databases.
• CEM checks your executives' current and past email addresses against breach corpora and leak databases. See the methodology.

To book an EDG3 briefing or see what CEM finds for your leadership team, contact us.

This article reflects the sources linked above as of 2 November 2026, 21:30 UTC. Ubuntu and Red Hat had not released fixed kernels at that time; we will update this article when they do.