Let me say the uncomfortable part first: the Linux kernel did its job here. The distributions did not, at least not fast enough, and the gap between those two facts is where real risk lives.

CVE-2026-98432 is a use-after-free in the kernel's IPv4 TCP handshake code, and it has been lurking since Linux 4.4. When the kernel finishes a TCP handshake, it hands the connection's IP options to the new socket without copying them. If that socket is torn down while another CPU is still building a reply from those options, the kernel can read memory it has already freed. The kernel's own CVE team rates it 9.8 out of 10, and for once the number is not hype: Anthropic's Frontier Red Team reported on 27 October that an unreleased Claude research model wrote a working exploit that ran commands as root on a Linux server with a multipath TCP (MPTCP) listener, with no login and no user interaction.

Read that again, slowly, because the details matter. The exploit was a lab demonstration, not a reported attack in the wild. Anthropic did not publish the exploit code, and as of late October no vendor advisory reported in-the-wild exploitation, nor was the flaw in CISA's Known Exploited Vulnerabilities catalogue. Panic is not the correct response. But neither is the shrug I keep hearing this week: "we don't run MPTCP, so we are fine."

That shrug is wrong twice over. The bug itself sits in the ordinary IPv4 TCP path, not in MPTCP code; the CVE record does not even mention MPTCP. And plenty of systems run MPTCP listeners without their operators knowing it: Go 1.24 programs listen with MPTCP by default, quietly widening the surface for exactly the kind of service that faces the internet. If you have not inventoried your listeners, "we don't run MPTCP" is a guess, not a fact.

The fix was the easy part

Here is the part that should embarrass the whole industry. The upstream fix, authored by Eric Dumazet and titled "ipv4: free inet_opt and ireq_opt after an RCU grace period," swaps two plain kfree() calls for kfree_rcu(), which simply waits until no reader is still using the options before freeing them. It landed in the stable kernels in mid-October (5.10.272 through 7.3), with the CVE record published on 15 October. Two lines, conceptually. Done, upstream, weeks ago.

And then the pipeline did what the pipeline does. Debian shipped fixed kernels. Amazon Linux shipped fixed kernels for several of its kernel packages. Oracle and SUSE shipped fixes for at least some releases. But as of 1 November, Ubuntu still listed its supported releases as vulnerable with fixes in progress, and Red Hat had deferred its fix to a future update for RHEL 8, 9, and 10. Running apt upgrade on an Ubuntu box on 1 November changed nothing, because there was no fixed package to install. That is the sentence I want every operator to sit with: your patching discipline cannot outrun a package that does not exist yet.

Backporting is real, unglamorous labour, and a tested package late beats a broken one early. But the industry keeps selling patching as if it were a command you run, when for weeks at a time it is a waiting game governed by somebody else's release queue. We saw the same pattern when six unpatched kernel flaws went public at once in October: disclosure is instant, fixes are not, and the window in between is measured in vendor timetables, not in your cron schedule.

Stop arguing about the score

The other embarrassment this week is the severity debate. The kernel team says 9.8, Red Hat now says 8.1, Amazon says 7.0. These are all defensible readings of how hard the race is to win in practice, and they are all beside the point for anyone running a public-facing server.

A score is a triage tool, not a verdict. When a flaw lets a remote, unauthenticated peer corrupt kernel memory during a handshake, and a lab has already demonstrated the full chain to root, the correct operator posture does not change between 7.0 and 9.8: inventory the exposure, test your mitigations, and install the fixed kernel the hour it lands.

The same goes for mitigations. Red Hat published an nftables filter that drops incoming IPv4 TCP packets carrying IP options, and AWS pointed at disabling MPTCP and dropping those packets as interim steps. Reasonable stopgaps, and Red Hat is honest that its filter cannot fully prevent the vulnerability and does not replace a fixed kernel. Do not close this ticket until the kernel is patched and the machine has rebooted. An installed but unbooted kernel fix is a press release, not a remediation; see our reboot-after-kernel-patch playbook.

What I am actually doing about it

So here is my own checklist, offered as one operator to another. First, check your vendor tracker, not just your package manager: the tracker tells you whether a fix exists, while apt upgrade only tells you whether one reached your mirror. Second, find your MPTCP listeners and Go services. Third, test any interim mitigation before trusting it: a filter that drops legitimate traffic with IP options is a self-inflicted outage wearing a security costume. Fourth, when the fixed kernel lands, patch and reboot promptly, internet-facing hosts first; treat it as a planned event, per our Linux 7.3 upgrade playbook.

And here is the opinion, stated plainly: open source fixed this bug faster than almost any proprietary vendor would have, and then the last mile ate the victory. The distribution pipeline, the testing queues, the staged rollouts, the deferred updates: that is where weeks go to die. Until we treat "time from upstream fix to installed, booted kernel on a production host" as the metric that matters, every future CVE will follow the same script: a great fix, a long silence, a scramble, and a post-mortem that blames the score.

The bug is bad. The gap is worse. Close the gap first.

Sources

  • Anthropic Frontier Red Team, 27 October 2026 (lab exploit demonstration against an MPTCP listener).
  • Linux kernel CVE record for CVE-2026-98432 (CVSS 9.8; CVE published 15 October 2026).
  • Ubuntu CVE tracker and Red Hat bulletin RHSB-2026-016 (status as of late October / 1 November 2026).
  • AWS security bulletin 2026-160-AWS (Amazon Linux fixed kernels; managed-service dates into early November 2026).
  • The Hacker News, 29 October 2026 (https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html); BytesNation (https://bytesnation.com/blog/cve-2026-98432-linux-tcp-handshake-use-after-free/).