There's a serious Linux kernel flaw doing the rounds, and it comes with a twist for anyone running custom software. The most alarming exploit claim needs a server with a multipath TCP listener, and if your app is written in Go, it may have opened one without anybody deciding to.
So this is one of those rare security bugs where your application code, and not just your server, is part of the question. Here's what's known and what I'd check.
What the flaw is
CVE-2026-98432 is a use-after-free in the code that sets up incoming IPv4 TCP connections. In plain English, the kernel can free a bit of memory while another CPU is still reading it. AlmaLinux says the bug goes back to Linux 4.4 and is reached by a SYN packet carrying IPv4 options, sent to a listening IPv4 TCP port.
That's the first packet of a connection, long before your login page or your application gets a look in. It's why the kernel's own CVE team scored it 9.8 out of 10, with no credentials and no user interaction needed. Red Hat now rates it Critical too, while noting that reliable code execution needs precise control of the heap.
Where multipath TCP comes in
Anthropic reported that an unreleased research model wrote an exploit that runs commands as root on "Linux servers with a multipath TCP listener". The exploit hasn't been published. CloudLinux says its kernel team couldn't reproduce the claim and that it knows of no exploitation in the wild. So treat the root exploit as claimed rather than proven.
Multipath TCP lets a single connection use several network paths at once. It sounds exotic. Here's the catch. Since Go 1.24, Go's net package has used it for listening sockets by default on Linux, where the kernel supports it. That's a reasonable default. It's just the sort of thing that never comes up in a meeting.
Whether a given program gets that behaviour depends on how it was built. Go's docs explain that the defaults follow the Go version in go.mod, so a module still declaring an older version keeps the older behaviour. The kernel has a say as well. The setting net.mptcp.enabled is 1 by default upstream, but distributions differ, and AlmaLinux ships with it disabled.
It isn't only about Go either. Plenty of infrastructure tools are written in it, so a reverse proxy or API gateway you installed from a package could be involved even if your own app is PHP or Python.
What to check
1. Is your kernel fixed? This matters most, whatever you find below. The kernel fix has gone into the maintained stable branches, but what counts is whether your distribution has shipped it, and that varies:
- Debian: fixed, in 6.12.113-1 for trixie and 6.1.190-1 for bookworm.
- Ubuntu: this morning the main kernels for 22.04 to 26.10 still showed as vulnerable, with fixes in progress. 20.04, 18.04 and 16.04 had no fix listed.
- Red Hat: RHEL 8, 9 and 10 are affected and the bulletin says fixes are being expedited, but it doesn't list any fixed kernels yet.
- AlmaLinux: patched kernels are in its testing repository.
A new kernel does nothing until you reboot into it. Automatic updates will often install one and then leave the old kernel running for weeks. Run uname -r and compare it with what your distribution lists as fixed.
2. Is anything listening on multipath TCP? Run sudo ss -Mlnp. It shows multipath TCP listeners and which process owns each one. Check containers as well, because that setting is per network namespace. A container has its own view, even though it shares the host's kernel.
3. Do you run Go programs? For each one, go version -m ./yourbinary shows the Go version it was built with and its embedded build information. If you've got the source, look at the go line in go.mod.
4. Do you actually need multipath TCP? Almost certainly not, unless someone chose it deliberately. The Go Security Team gives two ways to turn the default off for a program: set GODEBUG=multipathtcp=0 in its environment, or add godebug multipathtcp=0 to the main module's go.mod and rebuild. If you can do without it across the whole server, setting net.mptcp.enabled to 0 and restarting the affected services does it, as AlmaLinux explains.
Now the honest bit. None of this fixes the bug. The Go team calls per-program disabling "a fragile mitigation" and says systems without multipath listeners may be vulnerable to similar attacks. An empty list from ss means one published route is closed, not that you're safe. As the Go team puts it, the best fix is a patched kernel.
5. Waiting on a kernel? AlmaLinux and Red Hat both give a temporary nftables rule that drops IPv4 TCP packets carrying options. Red Hat is clear that it "cannot fully prevent" the problem and may disrupt workloads, so test it before you rely on it. Traffic between containers on the same host may bypass it. My earlier post on rob-sherwood.co.uk goes through the server side in more detail, though the distribution statuses and scores have moved since, so go by the vendor pages.
The bigger point for bespoke software
On a managed platform this is someone else's job. With custom software, the app and the server are a pair, and a flaw like this falls right in the gap between them. Whoever looks after the server may not know what the Go runtime does by default. Whoever wrote the app may never have logged in to the server.
So here's the useful question: if a flaw like this lands tomorrow, who checks your server and your code together, and how soon does a new kernel actually get rebooted into?
If the honest answer is "no idea", start by finding out who holds the keys. Our guide to what to do when your developer has left covers that, and this one covers getting back into a server you've lost access to.
If you'd like someone to take a proper look, our code audit is £250 + VAT and covers the code and the servers it runs on. If you'd rather hand the lot over, Look after it runs from £355 a month + VAT and includes hosting and security updates, with one person to call. For a server-only review, my health check does that.
Either way, check your kernel today. It'll take you two minutes.
Cheers, Rob
