Linux fixed this server flaw on 11 October. Check your distribution has.

· · Security Infrastructure

If your website, customer portal, or the app your developers built runs on a server you rent, it almost certainly runs Linux. So do most virtual servers, container platforms, and the cloud machines underneath them. Every one of those now needs a kernel update and a reboot, and for two of the most common versions of Linux the update had not arrived as of 1 November.

The kernel is the core of the operating system, the part that handles the network before any of your software sees a connection. The flaw, CVE-2026-98432, sits in that code. An attacker who has never logged in can send specially timed connection requests that make the kernel use memory it has already freed. The usual result is a crash. In one setup, it is complete control of the server.

What happened

The bug is in how Linux sets up incoming connections over IPv4, the version of the internet protocol nearly every server still uses. It dates back to Linux 4.4, released in 2016, so almost any Linux server that accepts connections is in scope: web servers, remote logins, databases, and container hosts. IPv6 connections are not affected by the main problem.

The kernel's own security team scores it 9.8 out of 10. Red Hat first rated it lower, because the timing is hard to get right, then raised it to Critical and published a security bulletin saying it is "expediting the release of fixes".

What changed the picture was Anthropic's write-up on 27 October. Working with its AI model, Claude, Anthropic found the bug, and Claude then wrote a working exploit that runs commands with full administrator rights ("root") on Linux servers with a multipath TCP listener, without any password. A failed attempt does not crash the server, so an attacker can simply keep trying. In Anthropic's test it took 53 minutes.

As of 1 November, nobody has reported attacks in the wild, and the flaw is not on CISA's list of known exploited vulnerabilities. Anthropic has not published its exploit. But Atlas noted code on GitHub describing how to trigger the bug within two days of the write-up.

The fix exists. Your server may not have it.

Linux's own developers shipped the fix between 11 and 18 October. Almost nobody runs that version directly. Servers run a distribution, such as Ubuntu, Red Hat Enterprise Linux, or Debian, and each distribution builds and ships its own kernel on its own timetable.

As of 1 November:

  • Fixed: Debian 12 and 13, Amazon Linux 2 and 2023, Oracle Linux's own kernels, and some SUSE releases.
  • Not fixed: Every affected Ubuntu release, from 16.04 to 26.10, which Canonical's tracker lists as vulnerable with fixes "in progress". Red Hat Enterprise Linux 8, 9, and 10, listed as affected with no fixed kernel yet.
  • In testing: AlmaLinux, a free rebuild of Red Hat's distribution, has put patched kernels in its testing repository rather than wait for Red Hat.

That gap between a fix being published and it reaching your machine has always existed. What is new is how quickly it can be used. Mozilla, writing about the same effect in Firefox, calls it the patch gap: a published fix shows an attacker exactly where the hole was, and AI models are making it far quicker to work backwards from the fix to an attack. A fix sitting in public for three weeks, unshipped by the biggest distributions, is that window.

The multipath TCP detail

Multipath TCP lets one connection use several network routes at once. It is off unless a program asks for it. The catch is that some programs ask by default. The Go team warned on 29 October that since Go 1.24, programs written in Go turn it on for every service they listen on, so a server can have the setup Anthropic attacked without anyone choosing it.

Do not read that as "no multipath TCP, no problem". The Go team, Red Hat, and AlmaLinux all say the underlying bug is in ordinary connection handling, and that servers without multipath TCP still need the fix.

Containers do not help either. A container uses its host's kernel, so a new container image changes nothing. The host has to be patched and rebooted.

What to do

If a host, agency, or IT provider runs your servers, send them four questions:

  • Which Linux distribution and kernel are our servers on, including any container hosts?
  • Have you installed the fix for CVE-2026-98432 and rebooted? When?
  • If your distribution has no fix yet, what protects us until it does?
  • Do any of our services run with multipath TCP switched on?

A rebooted server on a fixed kernel is the only complete answer. "We patch monthly" is not one.

If you run your own servers:

  1. Check your distribution's tracker, not the upstream version number. Distributions add fixes to older version numbers.
  2. If a fix is out, install it and reboot. A kernel update does nothing until the machine restarts into it.
  3. If no fix is out yet, Red Hat's bulletin gives an interim firewall rule. It drops incoming IPv4 connection requests that carry "IP options", extra header fields that normal traffic almost never uses and that the known trigger relies on. Red Hat says it reduces exposure but cannot fully prevent an attack. Test it before you rely on it, and remove it once you are patched. AlmaLinux warns not to use it on networks that rely on IPv4 security labels, which most small businesses do not.
  4. Look for multipath TCP listeners with ss -Mlnp, and move any servers that have one to the top of the list. Setting GODEBUG=multipathtcp=0 turns it off for a Go program, but the Go team calls that a fragile fix, not a replacement for the patch.
  5. Do not forget the boxes nobody logs into. Appliances, network storage, and cloud images with their own built-in Linux need updates from their makers.

If you are on managed hosting or a platform where you never see the server, the job is your provider's. Ask anyway.

How Steelwise can help

Knowing which of your systems run Linux, who is responsible for patching each one, and whether "we're on it" means a rebooted server is the kind of thing a short security review pins down. Get in touch if you would like a second opinion on your provider's answer.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.