A use-after-free in the Linux kernel’s IPv4 TCP handshake code, tracked as CVE-2026-98432, is rated 9.8 by the kernel’s own CVE team. The Hacker News reported on October 29 that the bug was introduced in Linux 4.4, and that Anthropic says its Claude model wrote a working exploit for it.
If you run Proxmox, TrueNAS SCALE, Unraid, or anything else on a Linux kernel, this one is yours to check.
What’s actually known
The bug is a race condition. Memory gets freed while another CPU is still reading it. According to a write-up from binadit, anyone who can send packets to a listening IPv4 TCP port can reach it, with no login and no user interaction. The main bug doesn’t apply to IPv6.
Upstream fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The fix credits Anthropic researcher Xinyang Ge with the report.
On October 27, Anthropic said Claude wrote an exploit targeting servers with a multipath TCP (MPTCP) listener. Per The Hacker News, leaking a kernel address took 48 minutes in Anthropic’s test, and reaching command execution took five more. Neither the CVE record nor the kernel fix mentions MPTCP. That link comes only from Anthropic’s post.
The Hacker News also notes the Go Security Team said that since Go 1.24, Go programs enable MPTCP by default on their listening sockets. A lot of self-hosted tooling is written in Go, so that detail matters.
The severity score is disputed
Not everyone agrees on the number. Red Hat’s CVE page first rated it Moderate at 5.9, saying no confidentiality or integrity impact had been demonstrated. Its machine-readable advisory later listed Important at 8.1. Oracle and SUSE rate attack complexity as high, which drags their scores down.
The exploit claim also comes from one vendor and hasn’t been publicly reproduced, as binadit puts it. As of the reporting, nobody had seen it exploited in the wild, and it wasn’t in CISA’s KEV catalog.
That’s a reason not to panic. It isn’t a reason to skip the update.
Patch status depends on your distro
Per The Hacker News on October 29, Debian had fixed trixie on October 16, and Oracle Linux’s UEK kernels were fixed the same day. RHEL 8, 9 and 10 were still listed as affected with no fix. By binadit’s account, Red Hat shipped fixed kernels on November 1, and AlmaLinux followed on November 2. Ubuntu had no fix released as of that write-up.
For Proxmox, binadit cites advisory PSA-2026-00080-1 and says the 7.0 kernel series is fixed at proxmox-kernel-7.0.14-25-pve or newer. I couldn’t pull that advisory up on Proxmox’s own forum thread, so check Proxmox’s security advisories directly before you trust that version string.
Two practical points from binadit apply to everyone. Don’t compare upstream version numbers against uname -r on a distribution kernel, because vendors backport fixes. And a fixed package does nothing until you reboot into it.
What this means for a home lab
Red Hat says no available mitigation meets its bar for being easy to deploy and stable. A stopgap nftables rule exists, but binadit notes it doesn’t survive a reboot and doesn’t cover everything.
So the useful question is what listens where. A Proxmox host, a NAS, and a media server all accept connections on your LAN. Anything reachable through a forwarded port is the exposed surface. Anything behind a VPN is much harder to reach, though a compromised device on your own network can still send it packets.
Where we land
We run Proxmox here, and we’d treat this as a reboot-this-week patch, not a wait-for-the-maintenance-window patch. The severity argument is real, but the cost of being wrong is root on the hypervisor, and that’s the box holding everything else.
The bigger lesson is about forwarded ports. If your Plex or Jellyfin box is reachable from the open internet, a kernel bug like this one is your problem on day one. If it’s behind Tailscale or a similar tunnel, you’ve bought yourself time. We’d rather patch on our schedule than on an attacker’s.
Check your distro’s advisory, install the kernel, and reboot. Then look at which ports you’ve forwarded.