CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code, scored 9.8 by NVD, and the fix is in the stable kernels but not yet in every distribution. A post that spread on October 29 said the exploit only works against multipath TCP (MPTCP) servers, so "nobody uses it, we have time." That is true of Anthropic's proof of concept. It is not what the CVE text says about the bug.
Our earlier post on Anthropic's exploit chains covered the research. This one covers the patch status and the part that deserves a second look. We did not run any exploit; everything below comes from the kernel CVE text, vendor trackers and Anthropic's write-up.
TL;DR
| Question | Answer |
|---|---|
| What is it? | Use-after-free of the IP options on a TCP child socket, reachable from a retransmitted SYN |
| Is it only MPTCP? | The CVE text names tcp_v4_syn_recv_sock(), the plain IPv4 TCP path. Anthropic's exploit used an MPTCP listener |
| Exploited in the wild? | No report found. Wiz lists no public exploit and no CISA KEV entry |
| Score | 9.8 (NVD data), 8.1 (Wiz), 7.0 (Amazon Linux). Sources disagree |
| Fixed upstream? | Yes: commit e3f33b0a1d89, in 7.3-rc7 and stable releases from 5.10.272 to 7.2.10 |
| Fixed in my distro? | Debian: yes for bookworm and trixie. Ubuntu: work in progress on its page. Check yours |
| What do I do? | Install your vendor's kernel update, reboot, confirm with uname -r |
What is the bug?
When a client's SYN arrives, the kernel keeps a request socket. In tcp_v4_syn_recv_sock() the request's IP options (ireq->ireq_opt) are handed to the child socket as inet_opt without being copied.
If the client retransmits its SYN, another CPU can process it for the same request socket and build a SYNACK. tcp_v4_send_synack() reads the options under rcu_read_lock() only. Meanwhile the child socket can be freed, and inet_sock_destruct() releases inet_opt with a plain kfree(). The SYNACK builder then reads freed memory in ip_options_build().
The CVE text traces this to commit 079096f103fa, which made request sockets process without the listener lock, so nothing stops the free. A second race exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program), where an old request socket and its clone share one options pointer.
The fix is small: use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(), which matches how other paths already free these options. IPv6 is not affected by the first race, because tcp_v6_syn_recv_sock() duplicates the options. An IPv6 migration variant is left to a separate patch.
Claimed vs verified: "only MPTCP servers are at risk"
| Claim | What we found | Status |
|---|---|---|
| Anthropic's proof of concept needs an MPTCP listener | Anthropic's post says the exploit reaches "Linux servers with a multipath TCP listener" | Matches the source |
| The bug itself is MPTCP-only | The CVE text names the plain IPv4 TCP functions and never mentions MPTCP. Anthropic does not say whether plain TCP is exploitable | Not supported by the CVE text |
| Mainly a denial-of-service risk | Anthropic describes a root shell in about 53 minutes (48 for a pointer leak, five more for commands) in a lab | Disputed: the researchers claim more than a crash |
| Published October 15, so this is old news | The CVE was published October 15 and updated October 24; Ubuntu's page shows an October 28 update. Many distro fixes are still pending | True, and the pending fixes are why it matters now |
| Nobody has exploited it | No in-the-wild report found; Wiz lists no public exploit or KEV entry | Unconfirmed either way, not proof of safety |
Our reading: whether a plain TCP listener can be driven to code execution is unknown to us. "Probably harder" is a reasonable guess; "not affected" is not something the sources say. If you run internet-facing Linux hosts, treat MPTCP as one exploit route and the TCP handshake as the vulnerable code.
Patch status by distribution
Checked on October 29, 2026. These change quickly.
| Source | Status | Version |
|---|---|---|
| Upstream stable | Fixed | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 (per Wiz); 7.3-rc7 |
| Debian bookworm | Fixed | 6.1.190-1 (DLA-4841-1) |
| Debian trixie | Fixed | 6.12.113-1 (DSA-6568-1) |
| Ubuntu 24.04, 22.04, 26.04 | Vulnerable, fix in progress | 6.8.0-149.149, 5.15.0-203.213, 7.0.0-43.43 listed as work in progress |
| Ubuntu 20.04 and older | Vulnerable, no fixed version listed | 14.04 is not affected |
| RHEL 8, 9, 10 | Listed as affected by Wiz | Check Red Hat's advisory |
| Amazon Linux | Fix pending, scored 7.0 | See the ALAS page |
Debian's tracker shows two different sid versions for the fix (7.2.10-1 and 7.2.13-1 in different tables), so check it directly if the exact version matters.
Check your exposure
uname -r # compare to the fixed versions above
sysctl net.ipv4.tcp_migrate_req # 1 enables the second affected path
sysctl net.mptcp.enabled # 1 means MPTCP sockets are allowed
ss -M -tln # listening MPTCP sockets, if any
On Debian and Ubuntu, apt list --upgradable | grep linux-image shows whether a kernel update is waiting. A kernel update only takes effect after a reboot. Also check cloud images and container hosts: containers share the host kernel, so patching the image does nothing.
What to do
- Install your vendor's kernel update where one exists, then reboot and confirm with
uname -r. - Where the vendor has no fix yet (Ubuntu at the time of writing), prioritise internet-facing hosts and watch the tracker, or move to a vendor kernel that carries the upstream commit.
- Turn
net.ipv4.tcp_migrate_reqoff if you do not rely on it. This is our suggestion, not a vendor workaround. - Keep inbound TCP from untrusted networks limited to the hosts that need it.
For a worked patch routine across Ubuntu, Debian, RHEL and Docker hosts, see the PHP2Shell patch guide.
What this means if you run coding agents
Developer machines and CI runners that expose a dev server, a database or an agent's local port to a network are Linux hosts with a TCP stack too. An agent runs as you, so a kernel-level bug on that host is a bug under your agent. Beam cannot patch a kernel. Its CVE check covers package dependencies, and the lists this entry with the fix details. Treat kernel updates as part of the same routine as browser updates after Anthropic's disclosure.
The wider point is speed: PHP2Shell showed how fast agents turn a public bug into a working exploit. A published CVE with an unpatched distro is the window. The October 2026 attacks timeline tracks this alongside the month's other incidents.
What we could not confirm
- Whether a plain TCP listener, without MPTCP, can be exploited to code execution.
- Whether anyone has exploited it outside Anthropic's lab.
- Exact backport versions for RHEL and Amazon Linux; check their advisories.
- The CVSS score the kernel CNA assigned: sources disagree.
We will update this post when Ubuntu and Red Hat publish fixed packages.
Frequently asked questions
Does CVE-2026-98432 only affect servers that run multipath TCP?
Not according to the CVE text. It describes tcp_v4_syn_recv_sock(), the ordinary IPv4 TCP handshake path, plus a second race in request socket migration. Anthropic's proof of concept targeted a multipath TCP listener, but its post does not say plain TCP is safe. Patch every internet-facing Linux host.
Is CVE-2026-98432 being exploited in the wild?
We found no report of it. Wiz lists no public exploit and no CISA KEV entry as of its page. Anthropic describes a root-shell proof of concept, which is research. The race is hard to win, but Anthropic says a lost race fails the handshake rather than crashing the host.
Which kernel versions contain the fix?
Wiz lists stable releases 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, plus 7.3-rc7. The upstream commit is e3f33b0a1d89. Debian lists bookworm fixed in 6.1.190-1 and trixie in 6.12.113-1.
Has Ubuntu shipped a fix?
As of Ubuntu's CVE page on October 29, supported releases were marked vulnerable with a fix in progress, for example 6.8.0-149.149 for 24.04 and 5.15.0-203.213 for 22.04. No fixed package was confirmed. Re-check the page before relying on it.
What is the CVSS score?
Sources disagree. The CVE record in our database and Ubuntu show 9.8 Critical. Amazon Linux scores it 7.0 and Wiz shows 8.1. The 9.8 vector assumes no privileges and no user interaction, which the race condition makes hard to achieve in practice.
Is there a mitigation if I cannot reboot yet?
No vendor workaround is documented. Reducing exposure is the only lever: limit which hosts accept inbound TCP from untrusted networks, and note that net.ipv4.tcp_migrate_req=1 enables a second affected path, so confirm it is off if you do not need it.
Related reading
- Anthropic's AI-built exploit chains: Chrome 156, Linux MPTCP and Windows QUIC
- PHP2Shell patch guide for Ubuntu, Debian, RHEL and Docker
- PHP2Shell and AI exploit speed
- Brotli CVE-2026-111497: affected software and detection
- Check dependencies for known CVEs in CI with Beam
- October 2026 attacks timeline
- Source: Ubuntu CVE-2026-98432
- Source: Debian security tracker
- Source: Wiz vulnerability database
- Source: NVD
- Source: Anthropic research post
Details are accurate as of October 29, 2026; distribution fix status changes often, so verify against your vendor's advisory. Beam is a local prototype and its features are described as documented today.