CVE-2026-98432: An AI-Built Linux Exploit Rides a Go Default. Patch the Kernel, Not the Flag
A research model turned a Linux kernel race into remote root. The servers most likely to be in range are the ones running Go code that never asked for the feature the exploit needs.
Plenty of Linux servers are running a network feature their owners never turned on.
That sounds like a setup for a scare story, but it is just how defaults work. Someone upstream decides a feature is useful, flips it on for everyone, and millions of programs inherit the choice without a single line of review. Usually nothing happens. This week something did.
On October 27, Anthropic's Frontier Red Team published a post describing a remote, zero-click exploit against Linux servers. No password, no user clicking anything, and the end result is commands running as root, the all-powerful administrator account ("remote root" in security shorthand). The bug behind it is now tracked as CVE-2026-98432, the public ID number used to track a known vulnerability. The exploit needs one thing from the target: a listener for multipath TCP, a networking feature almost nobody thinks about.
Two days later, the Go Security Team sent a notice with an uncomfortable line in it: "As of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux."
So the people most likely to be running the exact listener this exploit needs are the people who never chose to.
Here is what happened, why the obvious fix is the wrong one, why rebuilding your containers will not help, and the short list of things worth doing this weekend.
What an AI model actually found
Start with the bug, in plain terms.
When a computer accepts a new network connection, the kernel (the core of the operating system, which handles memory, hardware and networking) keeps a small record of options for that connection. The flaw is that under the right timing, the kernel can throw that record away while another processor core is still reading it. Security people call this a "use-after-free": a program keeps using memory after handing it back. Ubuntu's description is more precise. It is IPv4 TCP option memory freed before a safe waiting period ends, and the fix delays the free until that waiting period has passed.
Timing bugs are usually hard to exploit, because you have to win a race. This one has a nasty property. According to Anthropic, a lost race only fails the connection handshake. Nothing crashes. So an attacker can simply try again, and again. In Anthropic's proof of concept, "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution."
Read that as a home burglary. The first 48 minutes are spent jiggling the lock to learn where things are kept inside the house (security folks call this defeating KASLR, the kernel's habit of shuffling its memory layout). The last five minutes are walking in.
Two caveats from the source matter here. The post credits "an unreleased, internal research model," not a product you can buy, and it describes a lab demonstration, not attacks seen in the wild. And this was not a one-off: the same post counts 62 Chrome CVEs found and patched as of Chrome 156, all rated critical or high.
The point is not that AI is scary. The point is that finding and weaponizing kernel bugs used to take rare people a long time, and that cost just dropped.
Where Go comes in
Multipath TCP, or MPTCP, lets one connection use several network paths at once. Think of a phone that keeps a video call alive while it switches from Wi-Fi to cellular, instead of dropping and reconnecting. An MPTCP listener on a server simply says "if a client wants to use multiple paths, I'll accept that." If the client does not ask, the connection falls back to plain TCP, which is why an MPTCP contributor (matttbe) argues in the Go issue thread that enabling it on servers costs little.
Go used to leave MPTCP off unless a programmer asked for it. Go 1.21 added support "only used if the application explicitly asked for it," per the GODEBUG documentation. Then Go 1.24, released in February 2025, changed the default: ListenConfig "now uses MPTCP by default on systems where it is supported (currently on Linux only)." In GODEBUG terms, the default became multipathtcp=2, meaning on for listeners and off for outgoing connections.
On the kernel side, the switch that allows MPTCP sockets at all, net.mptcp.enabled, is documented with "Default: 1 (enabled)" in the kernel's own docs.
Put those together. A web server, an API, an internal admin tool, a proxy, a model-serving sidecar: if it is written in Go, built under the 1.24 rules and opens an ordinary TCP listener on a Linux kernel with MPTCP enabled, it probably accepts MPTCP unless someone switched that off. Its author may have no idea.
One detail softens this. Go applies new defaults based on the go line in a project's go.mod file as well as the compiler version. The GODEBUG docs say that when a module declares an older Go version, "the Go toolchain amends its defaults to match that older Go version as closely as possible." A project that still says go 1.23 in its go.mod keeps the old, off-by-default behavior even when built with a newer compiler. So exposure depends on both.
Why the Go switch is the wrong fix
The tempting response is to set GODEBUG=multipathtcp=0 everywhere and call it done. The Go team offers that switch, plus a godebug multipathtcp=0 line for go.mod and a per-socket SetMultipathTCP(false) call. Then the same notice explains why none of them is the answer:
- Disabling MPTCP program by program is "a fragile mitigation." Leave one listener exposed and the machine is still exposed.
- The bug is not really about MPTCP. The notice warns: "It is possible that systems with no MPTCP listeners are vulnerable to similar attacks."
- "The best fix for this vulnerability is to upgrade to a patched kernel version."
Go maintainer Damien Neild (neild) made the same point more bluntly in issue #82717, which proposes turning the default off: changing it now would be "closing the barn door after the horse has left." He also questioned whether on-by-default was right in the first place, noting that Go appears to be unusual in doing it. The Go team called changing the default "premature," and as of October 31 the proposal is still open.
I came away from that thread thinking both sides are right, which is the frustrating part. MPTCP on by default is a defensible engineering choice. It also means a kernel bug in a path most people never use suddenly had a very large target list.
The broader lesson is about where to put your effort. Flags like GODEBUG and sysctl settings are tourniquets. They stop the bleeding while you get to the hospital. The hospital is a patched kernel and a reboot.
The patch gap is the real exposure
Anthropic says the fix landed upstream and was backported to all maintained stable kernel branches. Ubuntu points to upstream commit e3f33b0 in 7.3-rc7. That is fast. The slow part is everything after upstream.
As of October 30, Ubuntu's tracker rated the CVE 9.8 (CVSS 3.1) and listed its main kernels for 26.10, 26.04 LTS, 24.04 LTS and 22.04 LTS as vulnerable with fixes in progress. Amazon Linux lists its kernels as fixed. Debian's tracker shows fixed builds in the security suite while the default stable kernels are still marked vulnerable. Akamai's Linode opened a customer security advisory on October 30 saying it was taking mitigation actions.
Also note the date on Ubuntu's page: the CVE was published October 15, twelve days before Anthropic's post. The bug was public, in kernel-world terms, before most people heard about it.
And one trap catches teams every time. Rebuilding your container images does nothing here. Containers share the host's kernel. If your services run in Docker or Kubernetes on machines you manage, the fix lives on the host, and it only takes effect after a reboot (or a live patch your vendor explicitly says covers this CVE).
Put this into practice
Here is the lowest-friction path, roughly in order. Most of it takes minutes.
1. Find out what kernel you are running.
uname -r
Compare that version to your distro's tracker page for CVE-2026-98432 (Ubuntu, Debian, Amazon Linux, Red Hat and SUSE all have one). Match the exact package and flavor (generic, cloud, HWE), not just the upstream version number. If your provider manages the kernel for you, as with most serverless and managed container platforms, check their advisory instead.
2. See whether anything is listening with MPTCP.
sysctl net.mptcp.enabled
sudo ss -Mlnp
The first command shows whether the kernel allows MPTCP sockets (1 means yes). The second lists MPTCP listening sockets and the processes that own them, according to the ss manual (-M for MPTCP, -l for listening, -n for numbers instead of names, -p for processes). Run it with sudo so you see processes you do not own. Go services with active MPTCP listeners should show up. One catch: both commands only see the current network namespace, so containers and Kubernetes pods with their own network namespace need checking separately.
3. Check your own Go projects.
Look at the go line in each service's go.mod. If it says 1.24 or later and you never set multipathtcp, the service listens with MPTCP on Linux. To see exactly which non-default settings get compiled in, the GODEBUG docs give this command:
go list -f '{{.DefaultGODEBUG}}' ./cmd/yourserver
4. Buy time, if you cannot patch today.
The system-wide switch from the oss-security thread is:
sudo sysctl -w net.mptcp.enabled=0
John Haxby, who posted it, warns that newly started Go programs should cope but "running programs may have unexpected errors on new connections." Do it in a maintenance window, and restart services afterward. The setting is per network namespace, so set it where your listeners actually live. For a single Go service, GODEBUG=multipathtcp=0 in its environment works too.
Remember what these do. They take away the doorway Anthropic's exploit used. They do not fix the bug, and the Go team has said other doorways may exist.
5. Patch and reboot.
Install the fixed kernel package as soon as your distro ships it, reboot, and confirm with uname -r that the new version is the one running. Schedule it now, even if the package is not out yet, so the reboot does not wait for the next change window.
Honest limitations
A few things this story does not tell you, in plain words.
Nobody has published how many servers expose a vulnerable MPTCP listener. The exploit was shown in a lab. No source so far reports attacks in the wild. That is not a reason to wait; it is a reason not to panic.
Anthropic has not said which model found the bug or when it was reported, only that a research model did the work. Claims online that name a specific Claude model are going beyond the source.
The non-MPTCP risk is a warning, not a finding. The Go team says similar attacks without MPTCP are possible. It does not say anyone has built one.
And if your provider runs the kernel for you, most of this checklist is their job. Your job is to read their advisory and confirm.
The bigger point
AI models are getting good at the expensive half of security research: turning a subtle bug into something that works. That speeds up attackers and defenders alike. But it does nothing to speed up the part that has always been slow, which is getting a fixed kernel onto a machine and rebooting it.
This week also showed how little of your attack surface you chose. You did not decide your servers should accept multipath connections. A language did, in early 2025, for reasons that still make sense.
So the useful question for Monday is not whether AI found a scary bug. It is how many defaults your stack runs that nobody on your team ever reviewed, and how long your reboot window really is. You can answer both this weekend.
Sources: Anthropic Frontier Red Team, "Discovering and exploiting vulnerabilities in critical, real-world software with Claude" · Go Security Team notice via oss-security · Haxby reply · golang/go issue #82717 · Go 1.24 release notes · Go GODEBUG docs · Linux kernel MPTCP sysctl docs · Ubuntu CVE-2026-98432 · Debian tracker · Amazon Linux · Linode advisory · ss(8) manual. Sources read October 31, 2026.