Hacker News Reader

Comment by wiskinator | Hacker News Reader

> Anthropic says Claude wrote the exploit "after initial prompting," that it runs "arbitrary commands as root, without any credentials or user interaction" on servers with a multipath TCP listener, and that in its proof of concept "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution."

This is wild. I'm a firmware nerd, not a backend nerd, what percentage of TCP/IP servers are 'multipath'?

Also, since IPv6 isn't affected, wouldn't it be funny if this is what it took to get everyone to switch.

View on HN

My understanding is that an app explicitly needs to open a "multipath" socket. Go 1.24 does that by default, so does Caddy, these would be the big ones.

Your understanding seems to be wrong.

Every Ubuntu version in the last decade is currently vulnerable.

https://ubuntu.com/security/CVE-2026-98432

Patches not yet available. That makes this a big deal.

This article says that this isn’t app level but is level and can be exploited before requests reach apps.

> on servers with a multipath TCP listener

I was talking about the Anthropic blog post, only Go/Caddy enable multipath TCP listeners by default.

Well somebody is wrong, this blog post says:

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.

It reads like it was LLM generated though so who knows. There is at least a simple mitigation for Golang apps if that is the only concern.

Both are correct :)

Anthropic only exploited multipath TCP, but the bug is deeper and also affects TCP connections, but it looks like this path is harder to exploit, and it's unclear if anybody managed to.

Thanks. Expanding exploits is something LLMs seem pretty good at so I’d expect people to manage a more general exploit soon if not already. Hopefully it’ll be patched before that happens.

> what percentage of TCP/IP servers are 'multipath'?

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

only if it's enabled at the kernel level? I have this, and it's the defaults, on my RHELs:

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

and found not MPTCP listeners anywhere, including where I have caddy.

Reply on news.ycombinator.com