Contents

Ubuntu Servers Still Wait for a Fix to a 9.8 Linux Kernel Bug That an AI Turned Into a Root Exploit

 

Ethical Hacking Complete Course Zero to Expert

Hack like black hat hackers. Penetration testing, Kali Linux, WiFi and web hacking, and the hacker mindset behind it.

→ Take the full course
 
Contents

Linux servers on Ubuntu 22.04, 24.04 and 26.04 are 18 days behind Debian on a 9.8 kernel bug. 53 minutes, no password, and a server runs commands as root. An AI wrote that exploit, for a flaw that has sat in Linux TCP since 2016.

On November 3, Ubuntu’s own security page for CVE-2026-98432 still lists Ubuntu 22.04, 24.04 and 26.04 as Vulnerable, with a short note that work is in progress. The Linux kernel developers released the fix on October 15, and Debian shipped it to its users the next day. SUSE began releasing updates on October 29. Red Hat, which rates the bug Critical, the highest level on its scale, followed on November 1 for its Enterprise Linux 8, 9 and 10. The three Ubuntu versions still waiting are its long-term support releases, the releases built to run on a server for years, with five years of security updates by default.

The score of 9.8 out of 10 comes from the Linux kernel’s own CVE team. It means the bug can be reached over the network, without an account or a password, and without a person on the server clicking or opening anything.

The flaw came to light through Anthropic, the company behind the Claude AI models. In a research post published on October 27, its Frontier Red Team wrote that it found the bug with an AI model that has not been released to the public. After a first prompt from the team, the AI wrote a working exploit for it.

That exploit sends packets to a Linux server that has a Multipath TCP listener open. It ends with a shell command of the attacker’s choice running as root, with no login and no action needed on the server’s side. In their test it took 48 minutes to pull a kernel pointer out of the target, and about five more minutes to get the command to run. On the kernel side, the fix names Xinyang Ge, with an anthropic.com address, as the person who reported it.

To see why this works, start with the way a TCP connection opens. A computer that wants to talk to a server sends a small packet called a SYN. The server answers with a SYN-ACK, the computer sends an ACK back, and the connection is open. This is the three-way handshake, and it happens before a server sends back a single web page or login screen. An IPv4 packet can also carry a few extra fields in its header, called IP options, up to 40 bytes of them. When a SYN arrives with options attached, Linux keeps a copy of those options and echoes them back to the sender inside its SYN-ACK.

The trouble starts when the same SYN arrives twice, which is normal on the internet, because a client that hears nothing back in time simply sends its SYN again. A second processor core can then begin building a fresh SYN-ACK from those stored options, while the first core finishes setting up the connection and hands the options over to the new connection without copying them. When that new connection is freed, the options are freed with it, and the second core can still be reading from memory that no longer belongs to the connection. By then the kernel may already have handed that memory to something else.

When the result depends on which of two cores gets there first, that is called a race condition, and here it ends in a use-after-free, right in the code that answers incoming connections, on any port where a server listens.

In the first stage of the exploit, the race makes the kernel read a length field that the attacker controls. The kernel then copies extra bytes into its reply and sends them out, and among them is a kernel pointer, an address that shows where the kernel sits in memory. Linux shuffles that layout each time it starts, a protection called KASLR, so a remote attacker cannot predict it, and one leaked pointer is enough to undo it.

In the second stage, the same use-after-free is used to overwrite a callback pointer, an address the kernel will later jump to, so that it points at a payload the attacker staged earlier. That payload strings together functions that already exist inside the kernel, and the last of them runs the attacker’s shell command as root.

A race like this does not succeed on the first try, and that is where the 48 minutes come from. A lost attempt only breaks that one handshake, without crashing the server, so the attacker can keep sending attempts until one succeeds. The race also makes the attack harder to pull off than the score alone suggests. SUSE scores it 8.1 instead of 9.8, because it rates the attack complexity as high, and Red Hat writes that reliable code execution needs precise control over the kernel heap, the memory the kernel hands out while it runs.

The code change behind this bug is more than ten years old. On October 2, 2015, Eric Dumazet changed the way Linux stores incoming connection requests, so that they sit in the main lookup table while the handshake is still going on. That change shipped in Linux 4.4, released on January 10, 2016, and the kernels released since then carry the flaw. A second path into the same bug arrived in June 2021, through a feature that moves waiting connection requests from one listening socket to another. That feature is turned off by default.

Eleven years after the original change, on October 1, 2026, the same man wrote the fix. The engineer who added the second path in 2021 reviewed it. The patch itself is small: where the kernel used to free the stored options straight away, it now waits until no other processor core can still be reading them, using a method called RCU, which stands for read-copy-update. The options stay in memory for that short window, and only then does the kernel release them.

Multipath TCP, or MPTCP, is a version of TCP that lets one connection run over several network paths at the same time, for example over a wired link and a mobile link together. The exploit from the red team needs a server with an MPTCP listener. Ubuntu builds MPTCP into its 24.04 kernel on all supported architectures, and the Linux kernel turns it on by default.

On top of that, since Go 1.24, released in February 2025, programs written in Go open their listening sockets on Linux with MPTCP by default. A server program built with a recent version of Go, such as the Caddy web server, can therefore be listening with MPTCP on a stock Ubuntu 24.04 kernel without its administrator ever choosing it. The Go security team sent out a warning about exactly this on October 29.

Switching MPTCP off closes the route this one exploit takes, and the flaw itself stays in plain IPv4 TCP. A Red Hat security bulletin states that MPTCP is not required for the bug, and that OpenShift nodes, where MPTCP is disabled, are still affected. Canonical, the company behind Ubuntu, writes that the fix is not specific to MPTCP.

The reason Ubuntu is behind comes down to which kernel each distribution runs. Debian runs on the 6.12 kernel line, which received the fix in version 6.12.113 on October 15, so Debian only had to package it. Ubuntu 22.04 runs on its own build of the 5.15 line, and 5.15.223 with the fix came out on that same October 15. Ubuntu 24.04 runs on 6.8 and Ubuntu 26.04 on 7.0. The fix from the kernel developers did not come out for those two lines, so the Ubuntu kernel team has to carry it over itself.

That work is done: fixed kernels for 22.04 and 24.04 went into a section of the Ubuntu archive called -proposed on October 26, and the kernel for 26.04 followed on October 28. The -proposed pocket is Ubuntu’s testing area. Packages there are not picked up by a normal update, so a server only receives them when its administrator turns that pocket on by hand. In a blog post on November 2, Ubuntu wrote that the kernels are in qualification testing on more than 2,000 certified servers and devices. They move to the regular updates as soon as those tests are complete, and the post gives no date.

The same blog post describes the CVSS score of 9.8 as a severity of High, one step below Critical. The Ubuntu Server page promises timely patches for critical vulnerabilities to customers of Ubuntu Pro, the paid subscription. The older releases, Ubuntu 20.04, 18.04 and 16.04, only receive security fixes through that subscription, and all three are still listed as fix pending.

An Ubuntu server can be checked in a minute. The first command shows which kernel is running, the second lists the kernel packages that are installed:

1
2
uname -r
dpkg -l 'linux-image*' | grep ^ii

Two more commands show whether a server matches the setup of the published exploit. The first prints 1 when MPTCP is switched on, the second lists the listening sockets that use it, with the program behind each one:

1
2
sysctl net.mptcp.enabled
sudo ss -lnMp

For administrators who want the fixed kernel from the testing pocket now instead of waiting, Ubuntu gives these commands, and says this route is meant for teams that test kernels themselves before rolling them out. They turn on the -proposed pocket and install the kernel from it, and the server needs a restart afterwards. The install line assumes a kernel that was installed through a meta-package:

1
2
3
4
sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade
sudo reboot

For servers that cannot take that step yet, the same bulletin publishes a firewall rule that drops incoming IPv4 TCP packets with IP options, so the bug never gets its input. Save it as cve-2026-98432.nft:

1
2
3
4
5
6
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Then test the file and load it, and the last command confirms the table is active:

1
2
3
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

The rule has limits, and Ubuntu’s own CVE page spells them out:

  • → It covers the host itself, and containers with their own network setup need the rule applied separately
  • → It is gone after a reboot unless it is added to /etc/nftables.conf
  • → It breaks connections that depend on IPv4 options, such as CIPSO security labels
  • → IPv6 traffic does not need it, because IPv6 is not affected by the main bug

The bulletin calls the rule a way to reduce exposure and not a replacement for the kernel update. Ubuntu’s security team goes further and says the update itself is the only proper fix. Once the fixed kernel is running, the rule comes off again with sudo nft delete table inet cve_2026_98432.

So far there is no report of this bug being used in a successful attack, but the scanning has started. Security researcher Marcus Hutchins wrote on November 3 that a scan on October 30 found about 2.1 million servers reachable over MPTCP on port 443, without showing which of them are patched. Since November 2 his team has seen residential proxies and Russia-based VPN servers probing port 443 with MPTCP, which ordinary scanners do not use, and he suspects attackers looking for this bug. Denial-of-service proof-of-concepts are already circulating, and the exploit from the red team has not been released.

The CVE does not appear in the list of known exploited vulnerabilities kept by CISA, the US cybersecurity agency. Debian already has a fixed kernel, and so do the standard kernels of Red Hat Enterprise Linux 8, 9 and 10, while SUSE has fixes out for several of its versions with others still in progress. On those systems the fix only takes effect after the update and a reboot, when uname -r shows the new version.

On Ubuntu 22.04, 24.04 and 26.04, a plain sudo apt upgrade will not bring in the fix until it moves out of -proposed. A server there that reports nothing left to update can still be running the vulnerable kernel today.

The SYN, SYN-ACK and ACK at the center of this bug are packets you can capture and read yourself on your own network with Wireshark.

My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Ubuntu CVE-2026-98432 | Debian DSA-6568-1 | Anthropic Frontier Red Team | Linux kernel fix

 
NEWSLETTER

Stay updated

Get the latest posts in your inbox every week. Ethical hacking, security news, tutorials, and everything that catches my attention. If that sounds useful, drop your email below.

By Bulls Eye

Jolanda de koff • email • donate

My name is Jolanda de Koff and on the internet, I'm also known as Bulls Eye. Ethical Hacker, Penetration tester, Researcher, Programmer, Self Learner, and forever n00b. Not necessarily in that order. Like to make my own hacking tools and I sometimes share them with you. "You can create art & beauty with a computer and Hacking is not a hobby but a way of life ...

I ♥ open-source and Linux