Linux IPv4 TCP Use-After-Free CVE-2026-98432: Remote RCE

What to do

1. Run uname -r on every Linux host and compare it with your distribution's fixed kernel for CVE-2026-98432.
2. Install the fixed kernel and reboot into it, starting with internet-facing servers, load balancers and hosts running Go services.
3. Where no fix exists yet (Ubuntu, RHEL 9 kernel-rt, OpenShift), list MPTCP listeners with ss -Mltn and set GODEBUG=multipathtcp=0 for Go services or sysctl -w net.mptcp.enabled=0 if nothing needs MPTCP.
4. As an extra stopgap, drop inbound TCP packets that carry IPv4 options at your host firewall, after testing; this does not cover traffic between containers on the same host.
5. Keep net.ipv4.tcp_migrate_req at 0 and avoid BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programs unless you need them.
6. Track Ubuntu's CVE page and schedule the reboot window now so the update lands the day it ships.

How to check if you are affected or compromised

• Search kernel logs for oops or panic traces naming ip_options_build, ip_build_and_send_pkt or skb_under_panic (journalctl -k | grep -E 'ip_options_build|skb_under_panic').
• Look for bursts of inbound SYNs carrying IPv4 Record Route or Timestamp options in packet captures or IDS logs, for example tcpdump 'ip[0] & 0xf > 5 and tcp[tcpflags] & tcp-syn != 0'.
• Treat unexplained reboots or kernel crashes on internet-facing hosts as worth investigating; a quiet log does not prove a host was not targeted.

What happened#

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code. The kernel CVE team published it on October 15, 2026. It drew little attention until October 29, when the Go security team's announcement pointed to an exploit described by Anthropic: a server with Multipath TCP (MPTCP) listeners "can be remotely compromised." Anthropic's write-up says the exploit runs "arbitrary commands as root, without any credentials or user interaction." Its proof of concept took 48 minutes to leak a kernel pointer and five more to get command execution. The exploit code has not been released.

The CVE record explains the race. When a client sends a SYN carrying IPv4 Record Route or Timestamp options, the kernel stores those options with the request socket. When the connection completes, tcp_v4_syn_recv_sock() hands the same buffer to the child socket without copying it. A retransmitted SYN handled on another CPU can still be building a SYNACK from that buffer when the child socket is torn down and frees it with a plain kfree(). The fix frees the buffer only after an RCU grace period. The kernel CNA scored the bug 9.8. Its notes say the stale data can leak kernel heap contents in the SYNACK, steer out-of-bounds kernel writes, or crash the host.

Who is affected#

The bug is in Linux kernels 4.4 and later. The stable fixes are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, and the fix is in mainline 7.3. Distribution status as of November 2:

• Red Hat rates it Critical. It shipped fixed kernels for RHEL 8, 9 and 10 on November 1 (for example RHSA-2026:93412 for RHEL 9). Rescana's summary of Red Hat data lists RHEL 9 kernel-rt and OpenShift 4 as still unfixed.
• Debian has fixed trixie (DSA-6568-1) and bookworm (DLA-4841-1, DLA-4850-1), according to its tracker.
• Amazon Linux 2 and 2023 kernels were fixed between October 24 and 30.
• Ubuntu has no released fix. Fixes for 22.04, 24.04, 26.04 and 26.10 are in progress, and 16.04 through 20.04 are listed as vulnerable.

Do you really need to act?#

If your Linux servers accept TCP connections from networks you do not control, yes. The attacker needs no account. The race runs entirely during the handshake, and the attacker controls both sides of it.

MPTCP matters because it is enabled by default in more places than most teams realize. The kernel's net.mptcp.enabled setting defaults to 1, and the Go team says that since Go 1.24, Go programs open MPTCP listen sockets on Linux by default. Any modern Go HTTP or gRPC server on Linux therefore matches the setup Anthropic exploited. The Go team also warns that the bug "is not specific to MPTCP" and that hosts without MPTCP listeners may be open to similar attacks. Turning MPTCP off reduces exposure but does not remove it.

Reasons not to panic: no vendor, CERT or the kernel CVE team reports exploitation in the wild, the CVE is not in CISA's KEV catalog, and no public exploit exists. Red Hat notes that reliable code execution requires precise heap control. That puts this in patch-this-week territory, not drop-everything, but expect the window to shrink once someone reproduces the technique.

What to do now#

1. Check each host's running kernel with uname -r and compare it with your distribution's fixed version. Installing the package is not enough. You must reboot into the new kernel.
2. Patch internet-facing servers, load balancers, Kubernetes nodes and hosts running Go services first.
3. Where no fix exists yet, find MPTCP listeners with ss -Mltn. Then run Go services with GODEBUG=multipathtcp=0, or disable MPTCP for the whole host with sysctl -w net.mptcp.enabled=0 if nothing on it needs MPTCP (suggested on oss-security). Go processes that are already running may see errors on new connections after the sysctl change, so restart them.
4. Optionally, drop inbound TCP packets that carry IPv4 options. In an existing nftables input chain, for example: ip protocol tcp ip hdrlength > 5 drop. Test this first. A poster on oss-security notes that traffic between containers on the same host bypasses this filter. The same post suggests booting with init_on_free=1 to limit what the bug can leak. Neither measure is a fix.
5. Confirm sysctl net.ipv4.tcp_migrate_req returns 0. This covers only the second, migration-related path described in the CVE.

How to tell if you were hit#

The likeliest visible symptom of a failed attempt is a kernel crash. Search the logs with journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic' and look into unexplained reboots on exposed hosts. On the network, bursts of SYNs carrying IPv4 options from one source are unusual: tcpdump -n 'ip[0] & 0xf > 5 and tcp[tcpflags] & tcp-syn != 0'. A successful exploit would run as root and may leave no kernel trace, so clean logs prove little.

Timeline#

• Oct 15, 2026 — The kernel CVE team publishes CVE-2026-98432 with fixes in all maintained stable branches.
• Oct 24, 2026 — The first Amazon Linux 2023 kernel fix ships (kernel6.18).
• Oct 27, 2026 — Anthropic's research post describes a zero-click root exploit against MPTCP listeners.
• Oct 29, 2026 — The Go security team publishes guidance; a proposal to disable MPTCP by default in Go is opened (still undecided).
• Nov 1, 2026 — Red Hat ships fixed kernels for RHEL 8, 9 and 10. Ubuntu fixes are still in progress.

Vulnerability records

• CVE-2026-98432 · In the Linux kernel, the following vulnerability has been resolved: ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock()…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. CVE record — CVE-2026-98432 cve.org
2. Linux kernel — ipv4: free inet_opt and ireq_opt after an RCU grace period git.kernel.org
3. Go Security Team via oss-security — Protecting against CVE-2026-98432 when using Go programs (Oct 29, 2026) openwall.com
4. oss-security — system-wide MPTCP disable (Oct 30, 2026) openwall.com
5. oss-security — interim hardening: init_on_free and packet filter (Oct 31, 2026) openwall.com
6. Anthropic — Discovering vulnerabilities with Claude anthropic.com
7. Red Hat — CVE-2026-98432 access.redhat.com
8. Red Hat — RHSA-2026:93412 kernel security update access.redhat.com
9. Ubuntu — CVE-2026-98432 ubuntu.com
10. Debian security tracker — CVE-2026-98432 security-tracker.debian.org
11. Amazon Linux — CVE-2026-98432 explore.alas.aws.amazon.com
12. Go — proposal: net: Disable MPTCP by default (#82717) github.com
13. Linux kernel documentation — MPTCP sysfs variables docs.kernel.org
14. Go — Go 1.24 release notes go.dev
15. Rescana — Linux kernel TCP CVE-2026-98432 use-after-free rescana.com