Have you tried turning it off and on again?

Your “patch all Linux hosts” ticket will reassure you, right up until you find out the old kernel is still the one running.

It’s the most honest ticket you’ll write this year, and the least useful.

Imagine the council writes to say there’s a crack in the foundations of every house on your street. Very kind of them. Except the builders have only fixed some of the houses, the rest are on a waiting list, and nobody can tell you which ones still have someone living in them.

That’s CVE-2026-98432. It’s a use-after-free in the Linux kernel’s IPv4 TCP handshake, in every kernel from 4.4 onwards, and it’s reachable by anyone who can open a connection to your server without logging in. It all happens inside the kernel, before your application has even seen the request, so your app can be perfectly secure and still sit on a cracked foundation. The kernel’s own security team scored it 9.8 out of 10.

Isn’t a race condition hard to win?

That used to be the comforting bit. Anthropic’s researchers, who found it, had Claude write a working exploit that runs commands as root on Linux servers with a multipath TCP listener. And here’s the bit that should stop anyone relaxing: “a lost race only fails the handshake without crashing the whole system”, so an attacker can simply keep trying. Their proof of concept took 48 minutes to leak a kernel pointer and another five to get a root shell.

Fifty-three minutes. That’s shorter than most change advisory boards!

So where is it?

A CTO once told me the pain with log4j wasn’t the patching, it was not knowing where it was running. With Brotli and PHP, finding the affected copies cut the list down to something you could work through.

This time the answer is “everywhere you run Linux”. Web servers, databases, bastions, Kubernetes nodes, CI runners, the VM someone set up for a demo in 2023. Even your containers can’t help you, because a container reports its host’s kernel, so scanning images tells you nothing here. Discovery doesn’t shrink this list. It ranks it.

Which one goes first?

Not the one at the top of the spreadsheet. Rank by who can reach it:

• Reachable from the internet goes first. AWS also calls out Linux targets behind PrivateLink endpoint services and VPC Lattice TCP listeners.
• Anything running Go 1.24 or newer is next. The Go Security Team points out that Go programs open multipath TCP listeners by default, so you may have the riskiest setup without anyone ever choosing it. You can switch it off per program, but they’re blunt about it: “disabling MPTCP on a program-by-program basis is a fragile mitigation.”
• Things AWS runs for you come last. AWS has already patched the EKS control plane and says Lambda isn’t affected. Your self-managed EC2 instances, node groups on older AMIs and custom AMIs are still yours.

What if there’s no fix yet?

Of course, this is where it gets awkward. Red Hat, AlmaLinux, Debian and Amazon Linux have fixed kernels. As of 5 November, Ubuntu’s fixed kernels for 22.04, 24.04 and 26.04 were still being tested. So the same estate needs two different jobs: patch some hosts, and mitigate the rest.

The interim fix is a firewall rule that drops IPv4 packets carrying IP options. AWS’s version:

iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Remember, AWS also warns this rule “does not persist across reboots unless saved”, so someone has to own it until the real fix lands. (Spoiler: if nobody’s named, nobody owns it.)

When is “patched” actually patched?

I made this point about Brotli, so I’ll keep it short. AWS is unambiguous: “A kernel update and reboot is the only complete remediation for this issue.” An installed kernel you haven’t booted into is a nice file on disk. So yes, have you tried turning it off and on again? Check versions, not vibes.

What do I do this week?

1. Find out what each host is actually running. Run uname -r on hosts and Kubernetes nodes, not inside containers. On RHEL-family boxes, needs-restarting -r tells you whether a reboot is still pending. On EKS, kubectl get node -o wide shows each node’s OS image and kernel.
2. Find the multipath TCP listeners. ss -Mlnp lists them. An empty result tells you what to patch first, not that you’re safe.
3. Rank by reachability. Start with internet-facing, PrivateLink and Lattice targets, then the Go services, then everything else.
4. Patch and reboot where there’s a fix. Do it in order, with pre- and post-checks, and roll node groups onto the fixed AMIs.
5. Mitigate where there isn’t. Apply the firewall rule, save it, write down who owns it, and take it out once the vendor ships.

Step one decides how long everything else takes. The simple maths: every hour your engineers spend building the host list by hand is an hour the unpatched ones are still answering the internet.

Can a reboot really be that quick?

It can. For a Nordic digital marketing firm, our engine patched a database host end to end in about 22 minutes, including a graceful reboot, pre- and post-checks, and service validation. Multiply that across a fleet and you see why a maintenance-window queue isn’t the bottleneck you should be accepting.

Anyway, don’t be like me and close the ticket because the package manager said “done”. Here at Firemind we’ve built the IT Operations Engine to keep a current map of what runs across your cloud, patch it in the right order inside your rules, and hold higher-risk changes for a human to approve, with every step recorded. Scope a free pilot on one cloud environment: we’ll rank every Linux host in it by exposure and fix status, then patch and reboot it in order.

👉 Scope a pilot