NewsCompaniesFlawsGuides
Get the app

Linux servers: a flaw in how connections start could let a stranger take over, and Ubuntu and Red Hat have no fix yet

From the HARD Situation Room · First reported
For everything else happening in security now, see the Situation Room.

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP code: while a connection is being set up, the kernel can free some data too early and then read it again. The kernel's own rating is 9.8 out of 10. Anthropic, whose researcher reported it, says an unreleased Claude model built an exploit that ran commands as root on a server with a multipath TCP listener, in about 53 minutes. That exploit hasn't been published, and nobody has reported attacks. Debian, Oracle, SUSE and Amazon have fixed kernels for some versions; Ubuntu and Red Hat Enterprise Linux didn't as of 30 October.

A flaw in the code every Linux server uses to start a connection could let a stranger on the internet take one over, with no password and nobody clicking anything. Anthropic says its AI built a working attack. Some of the biggest Linux distributions don't have a fix yet.

Current event. First reported . Details may change as more becomes known; updates will be added to the timeline.

What happened

Every time a computer connects to a Linux server, the two sides shake hands first: a few small messages back and forth before any website, email or file is involved. A flaw in the code that handles that handshake could let a stranger take the server over in the middle of it. No password, no account, nobody clicking anything.

The flaw, CVE-2026-98432, has been in Linux since version 4.4, released in 2016. The kernel's own security team rates it 9.8 out of 10, critical. Red Hat, Oracle and Amazon rate it lower, 8.1, because the timing is hard to get right. It was fixed upstream in October, but the fix has to reach each Linux distribution, and then each server has to install it and restart. For two of the biggest, Ubuntu and Red Hat Enterprise Linux, it hadn't arrived by 30 October.

Timeline

  1. Linux 4.4 is released, with the flaw in it. Every version since is affected.[1]

  2. The flaw is published as CVE-2026-98432. The kernel's own security team rates it 9.8 out of 10, critical, and lists the fixed releases.[1]

  3. Anthropic says an unreleased Claude research model built a working exploit that ran commands as root, about 53 minutes from the first memory leak to the first command.[2][3]

  4. Atlas publishes each distribution's status and an interim firewall rule.[4]

  5. Ubuntu and Red Hat Enterprise Linux 8, 9 and 10 still have no fix. Both say fixes are coming.[3]

  6. HARD publishes its article, at High.

What went wrong

When a connection request arrives with extra IPv4 options attached, Linux keeps a copy of them while it sets the connection up. The fix's own description explains that one part of the kernel could throw that copy away while another part, replying to a repeated request, was still reading it. Reading memory that's already been handed back is called a use-after-free, and it's one of the most common ways attackers take control of a program. The fix, by Google's Eric Dumazet, waits until nothing could still be reading the data before freeing it.

A failed attempt doesn't crash the server, it only drops that one connection, so an attacker can keep trying until the timing lines up.

The attack happens before the server has said hello.

An AI wrote the attack

The flaw was reported by Xinyang Ge, a researcher at Anthropic. On 27 October, Anthropic said an unreleased Claude research model had gone further: it built a working exploit that leaked the kernel's memory, got past its defences and ran commands as root, the all-powerful administrator account, on a server listening with multipath TCP. It reportedly took about 53 minutes from the first leak to the first command. Anthropic hasn't released the exploit. Atlas found one public GitHub project that claims to trigger the race, and hasn't tested it.

That matters beyond this one flaw. The gap between a fix being published and someone being able to use the flaw has been shrinking for years. When a machine can write the attack in under an hour, the old habit of patching servers at the next maintenance window starts to look slow.

Who is affected

Your phone and laptop aren't the worry here. This is a flaw in servers: the machines that run websites, email, the family office's files, the business's apps, and the cloud accounts that hold your data. Most families don't run one themselves, but someone runs one for them. A home server, a network storage box or a security camera recorder may run Linux too, and those are often the machines nobody updates.

The question isn't whether you're affected. It's whether the people who hold your data know about this, and when they'll restart their servers.

How this reaches a family

  1. A Linux box nobody thinks aboutThe family office’s server, a network drive at home, the machine that records the cameras. It took the update, but nobody restarted it.
  2. HARDEngineerYour engineer knows every machine that holds the family’s data and who looks after it, asks them when the fix goes in, and keeps the boxes at home updated and on their own network.See how it works
  3. A stranger knocksSomeone on the internet sends it a connection request built to trip the flaw, and keeps trying until the timing works.
  4. They’re in as administratorFiles, backups and camera footage are theirs, and the box becomes a way into everything else on the network.
Where HARD comes in.With HARD, the greyed-out steps don’t happen.

What to do

  1. Ask whoever runs servers for you.The family office, your business's IT, a web host, the person who set up a home server. Ask whether they run Linux, whether their distribution has shipped the fix, and when they'll install it.
  2. An update isn't done until the server restarts.A new kernel only takes effect after a reboot. That goes for container hosts and cloud machines too.
  3. If the fix isn't out yet, ask about the firewall.Blocking IPv4 packets that carry IP options, which ordinary traffic almost never uses, closes the way in until the fix arrives. Turning off multipath TCP alone isn't enough.
  4. Don't forget the boxes at home.A network storage drive, a camera recorder or a small home server: check for a firmware update over the next few weeks, and keep it off the open internet if you can.

Or have someone ask for you. Knowing which machines hold the family's data, who looks after each one and whether they've patched, the week a flaw like this lands, is part of what private cybersecurity is for.

  • CVE-2026-98432 Not on CISA’s list of flaws being used in attacks. Look it up in Search.
  • Oracle every Oracle flaw being used in attacks
  • Linux every Linux flaw being used in attacks
  • Red Hat every Red Hat flaw being used in attacks

References

  1. ^ Linux kernel CNA (). “CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period”. The record: the use-after-free in IPv4 connection setup, the 9.8 rating, every version from 4.4 affected, and the fixed releases.
  2. ^ CSO Online (). “Anthropic AI model finds Linux kernel bug that leads to remote root access”. The 53 minutes from the first memory leak to a root command, and the fixed kernel versions.
  3. ^ BleepingComputer (). “Critical Linux kernel flaw allows remote root attacks on MPTCP servers”. Anthropic's account of the exploit, patch status on 30 October, and why turning off multipath TCP alone isn't enough.
  4. ^ Atlas (). “Linux's October 2026 TCP use-after-free: CVE-2026-98432”. Each distribution's status, the ratings other vendors gave it, who found and fixed it, and the interim firewall rule.

Situation Room articles are updated as events develop: updates are added to the timeline, and never edited away. Follow them by email or RSS.