CVE-2026-98432: A 2015 IPv4 TCP Bug Got a Remote Root Exploit, and Go Turned MPTCP On for You

a use-after-free that has been sitting in the IPv4 TCP code since Linux 4.4 just got a working remote root exploit, written by an AI model. the public chain targets servers with a Multipath TCP listener, but the bug itself is plain IPv4 TCP: any listener that accepts a SYN carrying IPv4 options reaches it. you probably do not think you run MPTCP. if you ship Go services built on 1.24 or later, the sloth has some bad news about what your listeners have been asking the kernel for.

the bug, in sloth speed

the kernel advisory is unusually readable, so here is the core of it, quoted: “tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it.” meanwhile “another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req().” the SYNACK path reads ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice.

translation: two CPUs touch the same IPv4 options blob during the handshake. one hands it to the new child socket, the child can free it, and the other CPU is still building a SYNACK out of it. that is a classic use-after-free race, and because optlen is read twice, a freed and reallocated object can change size between the check and the copy. the advisory also calls out the same shape during request socket migration when net.ipv4.tcp_migrate_req is enabled or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in play.

the fix is boring in the best way. commit e3f33b0a1d89 moves the free of inet_opt and ireq_opt behind an RCU grace period (a kfree becomes kfree_rcu), so readers under rcu_read_lock() can finish before the memory goes away. the bug traces back to commit 079096f103fa, which landed in the 4.4 cycle. so yes, roughly a decade of kernels.

why MPTCP is the demonstrated part

the race lives in ordinary IPv4 TCP. what Anthropic showed is that an MPTCP listener gives an attacker a much more comfortable path to turn the race into a reliable primitive. per BleepingComputer, remote code execution has not been publicly demonstrated against servers without an MPTCP listener. that is “not demonstrated”, not “not possible”, and CIQ is explicit that disabling MPTCP alone is not sufficient because the underlying bug is still reachable through plain TCP.

the scoring moved while the ink was drying, which tells you something on its own:

• Red Hat, early read (8.1, per CIQ on October 30): unauthenticated and network reachable, but attack complexity high because the race is hard to hit.
• Red Hat, now (9.8, Critical): attack complexity low. Red Hat says plain IPv4 TCP services in default configs are exposed with no special tuning, and that reliable code execution still needs precise heap control.
• Linux kernel CNA (9.8) and Anthropic: network reachable, no auth, and a working remote root chain exists. the public one rides an MPTCP listener, but the vulnerable code is plain IPv4 TCP.

the sloth’s position on scoring arguments is the same as always. a vendor score tells you how hard the vendor thinks it is. a working exploit tells you how hard it actually is for somebody with patience and compute. the 53 minute number is the one that should set your priority, not the 8.1 somebody had on the board last week.

the Go footgun nobody put in the change ticket

starting with Go 1.24, the standard library asks for MPTCP on TCP listeners on Linux by default when the kernel supports it. if MPTCP is unavailable it falls back to TCP, which is why nobody noticed. the effect is that a lot of Go network services, think API gateways, proxies, exporters, internal tools, quietly opened MPTCP listeners the day they were rebuilt on a newer toolchain.

we reproduced that on the lab box. a tiny Go program calling net.ListenConfig.Listen on 127.0.0.1:8443, built with go1.27.3, shows up twice in ss -Mltn: once as tcp and once as mptcp. same binary with GODEBUG=multipathtcp=0 and the mptcp row disappears.

the Go team posted a stopgap to oss-security on October 30: set GODEBUG=multipathtcp=0 in the environment, pin it in the main module with a godebug multipathtcp=0 line in go.mod, or call SetMultipathTCP(false) on the net.ListenConfig in code. that reduces the attractive MPTCP surface. it does not fix the kernel.

who is fixed and who is waiting

upstream stable fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, with the fix also in 7.3-rc7. distro status as reported on October 30 and 31:

• Debian: fixed in 6.1.190-1 for Debian 12 (Bookworm) and 6.12.113-1 for Debian 13 (Trixie), plus testing and unstable.
• Ubuntu: Canonical’s tracker listed 22.04, 24.04, 26.04 and 26.10 as vulnerable with kernel fixes in progress.
• RHEL: 8, 9 and 10 affected. RHEL 6 and 7 are listed as not affected. update, nov 1: Red Hat has since shipped fixed kernels for 8, 9 and 10 (RHSA-2026:93412 through RHSA-2026:93415).
• Rocky Linux: CIQ confirms 8, 9 and 10 affected and published interim firewall guidance.
• AlmaLinux: patched kernels available in testing as of October 30.
• Oracle Linux, Amazon Linux, SUSE: fixes released for some affected kernel versions.
• macOS: not affected. XNU is not Linux, despite what your one coworker believes.

interim controls while the vendor kernel bakes

CIQ’s interim mitigation drops inbound IPv4 TCP packets that carry IP options before they reach the vulnerable handshake code. real traffic almost never sets IPv4 options, so the blast radius is usually small, but test it on something you can afford to break first. the rule keys on an IPv4 header length greater than 5 words, which is what an options-bearing header looks like.

ordered by how much they actually help:

1. patch and reboot. a kernel package sitting on disk while the old kernel runs is a vibe, not a fix. check uname -r after the reboot, every time.
2. drop IPv4 TCP with IP options at the edge and on hosts. CIQ’s nft rule, or the equivalent on your load balancer or cloud firewall. this addresses the plain TCP path too, which is the part people forget.
3. shrink reachability. BleepingComputer’s advice to restrict access to trusted networks applies doubly to anything internet facing with a Go listener.
4. turn off MPTCP where you do not need it. GODEBUG=multipathtcp=0 or the go.mod pin for Go services, and net.mptcp.enabled=0 host wide if nothing legitimately uses MPTCP. this removes the demonstrated exploit path, not the bug.
5. hunt for crashes. a failed race attempt is likely to look like a kernel oops or panic in the TCP receive path. if your fleet has been rebooting “randomly” on internet facing boxes, pull the kdump and console logs before you call it hardware.

finding your MPTCP listeners

you cannot mitigate what you have not inventoried. on each Linux host, ss -Mltnp lists MPTCP listening sockets and the owning process. anything that shows up there that you did not deliberately configure is probably a Go binary built on 1.24 or later. cat /proc/sys/net/mptcp/enabled tells you if the kernel will even accept MPTCP. in a container fleet, run it on the node, not in the pod, because the socket table you care about belongs to the host kernel.

for a quick fleet view, push one read-only script through whatever you already use for remote execution (MDM, SSM, Salt, Ansible ad hoc) that prints the kernel release, the upstream floor for its branch, net.mptcp.enabled and the count of MPTCP listeners. we used exactly that in the lab check above. it flags by upstream version only, so treat any vendor kernel with a backported fix as a manual verify against the distro tracker.

what an AI writing this exploit actually means

the headline writes itself: “AI builds remote root”. the more useful takeaway is narrower. a hard race in a decade-old code path, rated high complexity by a major vendor only days earlier, went from advisory to working remote root in under an hour of model time. the cost of turning “theoretically exploitable” into “exploited” just fell, and vendor severity scores that lean on “exploitation is complex” are going to age badly. patch cadence built around CVSS bands assumed attackers were lazy. some of them now have a very patient assistant.

that cuts both ways. defenders get the same tools for variant hunting and patch diffing. but the bottleneck in most shops is not knowing about the bug. it is the reboot window nobody wants to schedule on a Friday.

the sloth take

a 2015 bug, a 2025 language default, and a 2026 AI exploit walk into your data center. the bug did not care about your threat model, the language default did not ask your change board, and the exploit did not read Red Hat’s score. inventory your MPTCP listeners today, drop IPv4 options at the edge, pin multipathtcp=0 in your Go services, and get the vendor kernel on and booted as soon as it ships. the sloth moves slowly. your kernel patching should not.

related reading on the site: the last Linux kernel item that needed a reboot window was Fragnesia, CVE-2026-46300, and the PHP2Shell chain on KEV, and edge Linux boxes are already being farmed by things like the ClingSTUN Linux edge botnet.

defensive takeaway: this one is not on KEV yet, which is exactly when a sane patch order that does not wait for KEV earns its keep.

if you have Linux edge boxes or Go services you cannot reboot this week, get a second set of eyes on the interim controls. Book a slot with Dark Edge Consulting.

lab scripts: detect and mitigate (no exploit)

two scripts, nothing fancier:

• detect_cve_2026_98432.sh reads your kernel version against the upstream fixed floors (6.12.113 / 6.6.115 / 6.1.160 / 5.15.200 / 5.10.249 / 5.4.305), inventories ipv4 tcp listeners, and prints VULNERABLE / PATCHED / UNKNOWN. no packets leave the box.
• mitigate_cve_2026_98432.sh is a dry run by default. with --apply it installs an nftables rule that drops inbound ipv4 packets carrying ip options (the interim control ciq describes). it will not pretend mptcp=0 is a fix, and it will remind you the real fix is the patched kernel plus a reboot.

download the lab scripts (zip)

sources

• BleepingComputer: Critical Linux kernel flaw allows remote root attacks on MPTCP servers (Oct 30, 2026)
• linux-cve-announce: CVE-2026-98432, ipv4: free inet_opt and ireq_opt after an RCU grace period
• Red Hat: CVE-2026-98432 (Critical, CVSS 9.8) and CIQ: mitigating CVE-2026-98432
• oss-security, Oct 30, 2026: CVE-2026-98432 discussion and Go team MPTCP stopgap
• LWN coverage
• OSV: CVE-2026-98432 fixed versions
• AlmaLinux: patched kernels available in testing
• CIQ knowledge base: CVE-2026-98432 interim mitigation for Rocky Linux 8, 9 and 10 (kb.ciq.com)