Affected Akamai ExAR customers have already received a detailed mapping of vulnerable assets with actionable mitigation steps.
On October 5, 2026, a fix for a use-after-free (UAF) vulnerability in the Linux kernel's IPv4 TCP connection handling was committed upstream. The flaw has existed since Linux 4.4.
On October 15, 2026, the Linux kernel CVE Numbering Authority (CNA) published it as CVE-2026-98432, with a CVSS 3.1 score of 9.8 (Critical).
On October 27, 2026, Anthropic, whose researcher reported the bug, disclosed an exploit that lets an unauthenticated remote attacker run commands as root on Linux servers with a multipath TCP (MPTCP) listener.
On October 29, 2026, the Go Security Team warned that Go versions 1.24 and later enable MPTCP on Linux listening sockets by default.
As of October 30, 2026, Ubuntu and Red Hat Enterprise Linux (RHEL) have not released fixed kernels.
In this blog post, we provide a technical breakdown of the vulnerability, an overview of affected versions, and mitigation guidance.
CVE-2026-98432 is a race condition in how the kernel frees the IPv4 options attached to an incoming TCP connection.
A TCP connection starts with a SYN packet. The kernel tracks the half-open connection in a request socket, replies with a SYNACK, and creates a full child socket when the handshake completes. If the SYN carries IP options (i.e., optional IPv4 header fields), the kernel stores them with the request socket and uses them to build the SYNACK.
When the handshake completes, tcp_v4_syn_recv_sock() hands these options to the child socket without copying them. Meanwhile, another central processing unit (CPU) can process a retransmitted SYN for the same request socket and build a new SYNACK from the same options. That path relies only on read-copy-update (RCU), a lock-free scheme in which shared memory must not be freed until readers finish.
Since Linux 4.4, request sockets are processed without the listener lock, the child socket can be freed while the SYNACK is still being built. inet_sock_destruct() frees the options with a plain kfree(), and ip_options_build() then reads freed memory.
A similar flaw exists when request socket migration is enabled (net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE Berkeley Packet Filter program), where tcp_v4_reqsk_destructor() also uses a plain kfree(). IPv6 is not affected by the first path.
Anthropic reported that its exploit uses the race to leak kernel memory and defeat kernel address space layout randomization (KASLR), then overwrites a callback pointer to run a command as root.
Because a lost race only fails the handshake, the attacker can retry until it succeeds.
Anthropic reported its root exploit on October 27, 2026, and has not released it. As of the time of writing, we are not aware of a public working exploit.
Linux kernel 4.4 and later are affected; earlier versions are not. On maintained stable branches, the vulnerable versions are:
Kernels from 4.4 onward on branches that no longer receive stable updates are also affected.
Eric Dumazet authored the fix, which replaces kfree() with kfree_rcu() in both destructors:
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ void inet_sock_destruct(struct sock *sk)
- kfree(rcu_dereference_protected(inet->inet_opt, 1));
+ kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ static void tcp_v4_reqsk_destructor(struct request_sock *req)
- kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));
+ kfree_rcu(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1), rcu);kfree_rcu() waits for an RCU grace period, so readers on other CPUs finish before the options are freed.
To keep your organization protected, we recommend that you upgrade to a patched kernel.
The fix is included in Linux 7.3 and in stable releases 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, and 7.2.10.
As of October 30, 2026, Debian, SUSE, Oracle Linux, and Amazon Linux 2023 have made available fixed kernels for some of their releases.
To confirm, use Akamai Guardicore Segmentation Insight queries to check the running kernel version and the status of the MPTCP-related controls:
SELECT
o.name AS os,
o.version AS os_version,
k.version AS running_kernel,
COALESCE(m.current_value, 'N/A') AS mptcp,
COALESCE(t.current_value, 'N/A') AS tcp_migration,
CASE
WHEN m.current_value = '1'
OR t.current_value = '1'
THEN 'FEATURE ENABLED — PRIORITY REVIEW'
WHEN m.current_value = '0'
AND t.current_value = '0'
THEN 'FEATURES DISABLED — PATCH CHECK REQUIRED'
ELSE 'UNKNOWN — PATCH CHECK REQUIRED'
END AS cve_2026_98432_status
FROM os_version o
CROSS JOIN kernel_info k
LEFT JOIN system_controls m
ON m.name = 'net.mptcp.enabled'
LEFT JOIN system_controls t
ON t.name = 'net.ipv4.tcp_migrate_req';Administrators can also check the settings directly:
sudo sysctl net.mptcp.enabled
sudo sysctl net.ipv4.tcp_migrate_reqTo determine whether any applications are listening on MPTCP sockets, run:
sudo ss -M -l -n -p -eThe following settings disable MPTCP and TCP request migration until the next reboot:
sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0To maintain the settings across reboots:
sudo tee /etc/sysctl.d/99-cve-2026-98432.conf <<'EOF'
net.mptcp.enabled = 0
net.ipv4.tcp_migrate_req = 0
EOFLoad and verify the persistent configuration:
sudo sysctl --system
sudo sysctl net.mptcp.enabled net.ipv4.tcp_migrate_reqDisabling MPTCP alone does not prevent exploitation; it only reduces the likelihood of triggering the race condition. Blocking packets containing IPv4 options may provide additional protection, but it can disrupt applications that depend on those options.
Upgrading to a patched kernel remains the recommended mitigation.
CVE-2026-98432 is a UAF in the Linux kernel's IPv4 TCP handshake code that an unauthenticated remote peer can trigger, and Anthropic reported a remote root exploit for it.
Fixed kernels are available upstream and from several distributions; we recommend that you apply them as they become available for your platform.
The Akamai Security Intelligence Group will continue to monitor, report on, and create mitigations for threats such as these for both our customers and the security community at large. To keep up with more breaking news from the Akamai Security Intelligence Group, check out our research home page and follow us on social media.
© 2026 Akamai Technologies
