TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8

"Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection. Anthropic, whose researcher reported it, says its Claude model wrote a working proof-of-concept exploit that runs commands as root on "Linux servers with a multipath TCP listener," with no credentials. Go programs open those listeners by default, per the Go Security Team. See the timeline."

I don't know of any Linux boxes running a multipath TCP listener in my care and I have quite a few. MP generally implies a router of some sort and the intersections in a Venn diagram continue to get smaller ...

This is still an issue and must be patched but I think it will be rare, very rare.

That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.

SYN packet #1 is received and added to a request queue for processing.

SYN packet #2 is received and is a retransmit of SYN packet #1. It is matched to SYN packet #1 already in the request queue and now there is shared state between both SYN packets #1 and #2 in the request queue.

CPU #1 takes on the task of processing SYN packet #1.

CPU #2 takes on the task of processing SYN packet #2.

CPU #1 responds back with RST packet #1 (e.g. requested TCP port is not open) and _should_ defer the destruction of the request socket for SYN packet #1, as other CPUs may still be processing the shared state for the request socket as is the case for retransmitted SYN packets.[1] However, this deferred destruction wasn't occurring, and CPU #1 was _immediately_ destroying the request socket/shared state for SYN packet #1.

CPU #2 races with CPU #1 and reads from the request socket/shared state for SYN packet #1 after its _immediate_ destruction by CPU #1.

Linux's IPv6 handling is unaffected because in this IPv6 scenario, there is no shared state between SYN packets #1 and #2 in the request queue. Instead, each request socket has duplicate data.

Someone more knowledgeable can confirm/correct me on the above please.

[1] https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#rc...

sudo tcpdump --immediate-mode -p -nn -i eth0 -vvv -c 1 'ip and (ip[0] & 0x0f > 5)'

to see if you even get them from upstream.

You can even ping it from outside with these packets in the meantime

ping -R -c 3 $IP

> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution

source: https://www.anthropic.com/research/discovering-vulnerabiliti...

  cat > /etc/nftables-ipopt.nft <<'EOF'
  table inet ipopt {
    chain pre {
      type filter hook prerouting priority raw - 10; policy accept;
      ip hdrlength != 5 counter drop
    }
  }
  EOF

If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?

Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.

Ubuntu has had kernels in the "proposed" component for several days now if you want to pull it in manually. Not yet pushed to "security" or "updates".

RHEL runs with MP-TCP disabled by default, they initially listed it as Important only to later raise it to Critical.

IMNSHO this makes them unfit for purpose. I think this is the nail in the coffin for Ubuntu for me.

https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...

sysctl -a | grep net.mptcp.enabled net.mptcp.enabled = 0

https://news.ycombinator.com/item?id=50330367

"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."

The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.

It would be great if they introduced mitigations for this vulnerability though.

Illustrative example: This CVE in a Rust matrix transpose code: https://github.com/advisories/GHSA-5gmm-6m36-r7jh

Conceptually, there is not really anything much simpler than a matrix transpose. So how did they manage to create a bug? To make it fast you need simd, which implied using unsafe, and the dimension check to make it safe used unsigned integers that could wrap around. So they same bullshit as in C.

Vibe code aside I feel targeted rewrites are becoming more and more justified.

no idea, but at least Tailscale and Caddy were opening MPTCP sockets on servers I checked.

https://www.openwall.com/lists/oss-security/

From experience OpenAI and Anthropic have pretty heavy safeguards in recent (public) models.

the model spins because it cant test its own guesses. what fixed it for me was emulating the actual device. qemu with the vendor rootfs, real binaries running, and then every claim becomes checkable: did the daemon actually parse my input, which uid is it under, what does its own log say. once it can check things it stops guessing, getting qemu to actually boot the thing was its own little hell though, took more tries than i want to admit.

the other thing i learned the hard way: most static findings die on reachability, not on exploit primitives. so i run them in the emulator first and kill the unreachable ones cheap, before spending any time on heap work

on heap vs stack, i think that intuition is desktop shaped. device userland usually has weak or no mitigations, heap uafs are way more tractable there than youd expect

Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?

[1] https://community.ui.com/releases/dd0283dc-bf71-4140-ae1d-c1...

  root@OpenWrt2:~# lscpu
  Architecture:        mips
  Byte Order:          Little Endian
  CPU(s):              4
  On-line CPU(s) list: 0-3
  Model name:          -
  Model:               MIPS 1004Kc V2.15
  Thread(s) per core:  2
  Core(s) per socket:  2
  Socket(s):           1

An entire ecosystem of malware crawling and cohabiting in them.

If you have services open on the IPv4 net however, close them immediately as a precaution.

https://www.reddit.com/r/openwrt/comments/1xka85h/is_the_ope...

They say 25.12-SNAPSHOT has it fixed

Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).

It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.

AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.

[1] https://docs.kernel.org/networking/mptcp.html#sockets-api

Surely you understand why they wouldn't want to publicize a PoC, right?

Planning with Claude, implementation with Kimi.

The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!

I agree, but as yet we have no idea how much pain we have to pass through to get to the other side.

    # CVE-2026-98432 mitigation: drop TCP packets carrying IPv4 extended options
    -A ufw-before-input -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

This works for me on multiple servers and home desktops and my hardware linux firewall/router. I did it a couple days ago when this was first announced. The iptables counter for matches haven't gone up at all on my VPS servers that gets lots of traffic. The counter only goes up when I manually trigger it to test. Everything continues to work nominally with these in place.

i’d focus on writing new stuff with rust though, not rewriting old stuff

and time will tell whether it actually reduces bugs or just change the failure modes to something else

also C will always be there in some way or the other, at least in conventions and syntax