An AI just weaponized a 20-year-old kernel bug — your exposure depends on a feature you never chose

Here's the part of the CVE-2026-98432 story that the headlines keep skipping: the exploit is scary, but the exposure question is quieter and more specific than "all Linux servers are on fire." The flaw is a race-condition use-after-free in the kernel's IPv4 TCP connection setup code, and Anthropic's unreleased Claude research model built a working zero-click exploit against it — kernel memory leak, KASLR defeated, kernel control flow hijacked, root shell, in about 53 minutes of automated exploit development. The Linux kernel CVE team scored it 9.8. It reaches back to kernel 4.4. As of October 29, neither Ubuntu nor RHEL had shipped a fixed kernel.

The MPTCP detail is what makes triage interesting. Demonstrated remote code execution requires a server with a Multipath TCP listener — and neither the CVE record nor the upstream fix actually mentions MPTCP. That linkage comes from Anthropic's own writeup. So "am I vulnerable?" is not answered by your distro banner; it's answered by asking whether anything on your box opens an MPTCP socket. Ordinary TCP hosts are affected by the bug, but no public RCE proof exists against them. Here's the trap: as of Go 1.24, Go programs enable MPTCP by default on the sockets they listen on. A whole generation of Go services shipped without anyone deciding to be MPTCP servers are now candidates. If you run Go microservices on kernels 4.4 and up, you're in scope whether you ever heard of Multipath TCP or not.

The Hacker News Logo
Source image 1

The operational lesson is about tempo, not any one CVE. A research model found a latent kernel bug, weaponized it end-to-end, and handed the public a 9.8-rated hole before Ubuntu and RHEL had builds ready — while Red Hat, Amazon, Oracle and SUSE scored the same flaw between 5.9 and 8.1, which is your patch queue's next fun debate. Distros had twenty-odd years to trip over this race condition; the exploit took under an hour to develop once an AI looked for it. Bug discovery speed and patch distribution speed used to be roughly in balance. They aren't anymore, and the burden slides onto whoever operates the machines: audit your listeners (ss -ltnp plus whatever your service framework defaults to), know which of your hosts actually speak MPTCP, and treat "waiting on the distro" as a measured risk now rather than the default posture.

Source article image
Source image 2

When a model can find and weaponize a two-decade-old kernel race condition faster than a distro can build a kernel, does "wait for the vendor patch" still make sense as standard practice — or do we need a patching norm that assumes AI-scale discovery?

Sources

Comments

Post a Comment

Popular posts from this blog

AI Is Starting to Feel Less Like a Gadget and More Like Infrastructure

Image
Modern AI doesn't replace infrastructure — it runs on top of it. (Photo: Unsplash) For a while, AI coverage had the energy of a mall demo kiosk: very shiny, slightly chaotic, and usually one prompt away from embarrassment. Lately, though, the more interesting story is less about flashy demos and more about infrastructure. A useful CNBC piece argued that AI is not simply going to vaporize enterprise software overnight, and that sounds about right. In real companies, software does not disappear just because a model can summarize a meeting or write a decent SQL query. What actually happens is messier and more practical: AI starts sneaking into the plumbing. It shows up in search, support workflows, procurement tools, analytics dashboards, and data pipelines. The real winners may not be the loudest chatbot wrappers, but the vendors that make enterprise systems easier to operate, easier to query, and slightly less soul-crushing for the humans trapped inside them. That is less cinematic ...
Read more

When Two AI Bots Finally Learned to Talk in Discord

I spent part of the day doing something that sounds like the setup for a bad joke: getting two local AI assistants to talk to each other in the same Discord channel. Not through a web UI. Not by bouncing prompts manually between windows like a human message queue. In the actual shared channel, where both could see the conversation and react to each other. The funny part is that the problem was not intelligence. It was manners. Both bots were defensive by default around bot-authored messages, which is the sensible setting if you do not want your infrastructure turning into a recursive support group. The downside is obvious: if both assistants treat other bots as suspicious background noise, they will never coordinate on anything more useful than silence. The fix was to make both sides accept bot-authored messages only when they were explicitly mentioned. That detail matters more than it sounds. Blanket bot acceptance is how you end up with two enthusiastic systems discovering each oth...
Read more

2.9 Billion Commits a Month, and Nobody Asked Who Checks Them

Image
GitHub's CTO has posted a postmortem that admits something a hyperscaler rarely says out loud: the growth explains it. On August 17, GitHub was down for seven hours and forty-seven minutes — not because of a bad deploy or a bad config change, but because traffic hit a new peak and a critical component in its Central US data center failed to scale with it. Recovery was made uglier by a client-side retry loop that kept hammering the platform while it came back up, which is a nice picture of what happens when a lot of automated clients retry without backoff. The number sitting behind all of it is the interesting one: monthly commits went from 1.4 billion to 2.9 billion in four months. For years, the commit curve tracked the developer population almost one-to-one. It just stopped. GitHub's own postmortem frames it as a capacity story — 3 million added CPU cores, 120 petabytes of storage, Azure now serving 58% of platform load up from 12% in May — and for GitHub, that is fixable wit...
Read more