CVE-2026-98432: CVSS 9.8 Linux Kernel Flaw Can Be Triggered Via TCP Packages, Ubuntu and RHEL Not Patched

CVE-2026-98432 is a use-after-free vulnerability in the Linux kernel code that handles opening TCP IPv4 connections, with a CVSS score of 9.8 from the kernel CVE team. This flaw can be reached over the network without logging in, before any application accepts the connection, and has been in the kernel since Linux 4.4, which was released in early 2016.

The fix has made its way to all upstream stable kernel branches, and Debian, Oracle Linux, SUSE, and some Amazon Linux have released patched kernels. The problem is, as of October 31, 2026 , Ubuntu and Red Hat Enterprise Linux (RHEL) have not released improved kernels, even though they are both most widely used on servers. This article discusses how the loophole works, the status of each distro, how to check your server, and dampening measures that can be installed today.

CVE-2026-98432 Summary

How does this loophole work?

When a client opens a TCP connection, the kernel stores a "half-finished request" (socket request) until the handshake is complete. If the SYN packet from the client carries an IPv4 option such as Record Route or Timestamp, that option is stored with the request.

Once the handshake is complete, the kernel passes the options to the new socket without copying them. At the same time, another CPU could be processing SYN retransmissions for the same connection and reading those options to construct a SYNACK reply. If the new socket is destroyed first, the option is freed with a regular kfree(), while the other CPU is still reading it. This is use-after-free.

According to the kernel CVE team's assessment notes, the impact could be three kinds:

• Kernel memory leak. Stale data can also be sent in a SYNACK reply to the attacker.
• Memory corruption. Out-of-bounds writes in kernel memory that can potentially hijack the execution flow.
• Kernel crash (denial of service).

This pattern emerged since the commit that made socket requests processed without holding the listener lock, which came in in Linux 4.4. The fix is ​​small: the option memory is only freed after all CPUs have finished reading it ( kfree_rcu()). IPv6 paths are not affected because the kernel copies the options. There is also a secondary path via socket request migration, but that path is only active when net.ipv4.tcp_migrate_req=1, which is off by default.

Why is it called dangerous even though the scores are different?

This loophole was reported by Anthropic's Xinyang Ge. On October 27, Anthropic published research that said its internal AI model successfully created a zero-click remote exploit that resulted in command execution as root on a server that had a Multipath TCP (MPTCP) listener.

The exploit works in two stages. First, race is used to leak kernel addresses so that KASLR protection can be bypassed. Second, the same vulnerability is used to overwrite a callback pointer so that the attacker's commands are executed as root. A failed race only aborts one connection attempt without crashing the system, so an attacker can keep trying. In the Anthropic test, the first stage took 48 minutes and the second stage 5 minutes. The exploit code, kernel version, and test configuration are not published.

Differences in scores between vendors stem from two assumptions:

Since there are already credible demonstrations of root exploits, treat this loophole as remote code execution, whatever the numbers show up on your scanner.

Which distros already have the patch?

The statuses below are summarized from each vendor's official page as of October 29-31, 2026. These statuses may change daily, so double-check the vendor links in the Resources section.

One important note for Ubuntu users: the version numbers listed on the Ubuntu page (e.g. 6.8.0-149.149 for 24.04 and 5.15.0-203.213 for 22.04) are versions in progress, not packages that can already be installed. As long as the status is not "Released", apt upgrade does not provide a secure kernel.

How do I check my server?

1. Is the running kernel patched?

Large distros backport, so the kernel version number cannot be directly compared with the upstream version list. A more accurate way is to look for the CVE ID in the running kernel's changelog.

# Kernel yang sedang berjalan
uname -r

# Ubuntu / Debian
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -c CVE-2026-98432

# RHEL / Rocky / AlmaLinux / Oracle / Amazon Linux
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

# SUSE
rpm -q --changelog kernel-default | grep -c CVE-2026-98432

A number above 0 means the kernel contains a fix. On Ubuntu and RHEL the result is still 0 for now.

Also remember that a new kernel that has been installed means nothing before the server is rebooted, unless you use a livepatch that specifically covers this CVE.

# Ubuntu / Debian: ada kernel baru yang menunggu reboot?
[ -f /var/run/reboot-required ] && echo "Perlu reboot"

# RHEL dan turunannya
needs-restarting -r

2. Is there a service that listens with MPTCP?

The Anthropic exploit targets servers with MPTCP listeners, and there may be more of them than you think. Since Go 1.24, Go programs on Linux by default open listeners with MPTCP when the kernel allows, and Ubuntu 26.04 reportedly enables MPTCP by default.

# Daftar listener MPTCP beserta prosesnya
sudo ss -lnMp

# Apakah MPTCP aktif di kernel? (1 = aktif)
sysctl net.mptcp.enabled

If the first command displays nothing, it means there are no services listening with MPTCP. But that doesn't mean the server is secure: the loophole is in the normal IPv4 TCP path, and no one has confirmed that a server without MPTCP can't be hacked in a similar way.

3. Is the socket request migration path down?

sysctl net.ipv4.tcp_migrate_req   # harus 0 (default)

Temporary mitigation while the patch is not yet available

Red Hat says there are no mitigations that meet its standards, and no vendor has officially recommended the steps below. Consider everything an additional layer of defense, not a replacement for a patched kernel, and test it on a non-production server first.

Block IPv4 TCP packets carrying IP options

The vulnerability is triggered by SYN carrying the IPv4 Record Route or Timestamp option. Normal traffic almost never carries IP options, and RFC 7126 even suggests routers and firewalls discard packets with them. IPv4 headers without options are always 20 bytes (value hdrlength 5), so the following nftables rule only captures packets carrying options:

sudo nft add table ip cve_2026_98432
sudo nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
sudo nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

# Cek aturan aktif dan berapa paket yang sudah dibuang
sudo nft list table ip cve_2026_98432

This rule only discards packets, so it doesn't open any ports, and can run alongside either ufw or firewalld. The author of this rule tested that SYN with Record Route is indeed wasted while the regular connection continues, but did not test against a real exploit. Some notes:

• Don't install it on a network labeled as using CIPSO (SELinux/Smack NetLabel), because there the IP options are used normally.
• If the server also routes traffic to other machines, TCP packets with IP options that pass through will also be discarded.
• Rules created with the above command are lost after reboot.

To persist after reboot without interfering with ufw or firewalld rules, save the rules in a separate file and load them via the systemd unit itself. Don't add it to Debian/Ubuntu's default /etc/nftables.conf, as that file starts with flush ruleset which will remove other firewall rules when loaded.

sudo tee /etc/nftables-cve-2026-98432.nft >/dev/null <<'EOF'
table ip cve_2026_98432
flush table ip cve_2026_98432
table ip cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    meta l4proto tcp ip hdrlength gt 5 counter drop
  }
}
EOF

sudo tee /etc/systemd/system/cve-2026-98432.service >/dev/null <<'EOF'
[Unit]
Description=Mitigasi sementara CVE-2026-98432 (drop TCP IPv4 ber-IP options)
Wants=network-pre.target
Before=network-pre.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/nft -f /etc/nftables-cve-2026-98432.nft
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now cve-2026-98432.service

In RHEL and derivatives, write files directly in /etc as in the example above. Moving files from /tmp to mv brought the wrong SELinux labels so nftables failed to read them on boot. Once the repair kernel is installed and the server is rebooted, turn off this unit and clear the table.

Reduce MPTCP listeners

• Go programs: the Go security team recommends environment variables GODEBUG=multipathtcp=0, or godebug multipathtcp=0 in go.mod if you build your own. Code that calls SetMultipathTCP explicitly will ignore this setting.
• System-wide: sudo sysctl -w net.mptcp.enabled=0 prevents the creation of new MPTCP sockets, but already open listeners remain MPTCP. Restart every service that appears at ss -lnMp, then run the command again until it comes up empty. Keep it at /etc/sysctl.d/ to persist after reboot.

The Go team itself calls turning off MPTCP per program a fragile mitigation: one missed listener is enough, and the underlying bug is not MPTCP specific. So this step reduces exposure, not closes it.

Monitor for signs of crashes

Failed or abusive exploit attempts can trigger kernel oops. Look for the function name associated with this gap in the kernel log:

journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic'

Checklist for today

1. Kernel inventory: distros, kernel variants (generic, -aws, -azure, -gcp, UEK and others), and versions currently running on each server.
2. Patch and reboot on distros that already have the fix: Debian, Oracle Linux UEK, SUSE, and Amazon Linux 2023 package kernel6.x.
3. Prioritize internet-exposed servers with open TCP ports over IPv4, especially those running Go services or MPTCP listeners.
4. On Ubuntu and RHEL, install nftables rules, reduce MPTCP listeners, and ensure tcp_migrate_req remains 0.
5. Monitor the Ubuntu and Red Hat CVE pages. Once the status changes to Released or Fixed, install the kernel, reboot, then double-check the running kernel changelog.

Frequently asked questions

Is my Ubuntu 24.04 server vulnerable?

Yes. As of the last update of the Ubuntu page on October 29, 2026, kernel linux for 24.04 is still in vulnerable status with a fix being worked on. The same goes for 22.04, 26.04, and 26.10, as well as cloud kernel variants like linux-aws, linux-azure, and linux-gcp.

I use shared hosting or managed VPS. What needs to be done?

The kernel is provider managed, so ask about their status. Some hosting providers have installed livepatch without rebooting, for example SiteGround, while CloudLinux is still preparing the kernel and livepatch for CloudLinux 8. If you have root access on your VPS, the check and mitigation steps above still apply.

Is IPv6 safe?

The main path of this loophole is only in IPv4, because the kernel copies options on IPv6 connections. There is a limited IPv6 variant of the migration path with the CALIPSO option, which will be fixed separately.

Has it been exploited in the real world?

No vendor or CERT has yet reported an actual attack, and this flaw has not yet been cataloged by CISA KEV. But the root exploit has been demonstrated, and the technical details of the loophole are public. Don't wait for reports of attacks to act.

Are containers affected?

Containers use the host kernel, so what needs to be patched is the kernel on the node or host. This also applies to Kubernetes and OpenShift 4 nodes.

Can I cherry-pick the patch myself?

The kernel and Ubuntu CVE teams both advise against cherry-picking a single fix. If you build your own kernel, use the latest stable release in your branch (5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, or 7.3).

Source

• CVE-2026-98432, Ubuntu Security
• CVE-2026-98432, Red Hat
• CVE-2026-98432, Debian Security Tracker
• CVE-2026-98432, CVE.org
• Upstream fix commit e3f33b0, kernel.org
• Discovering vulnerabilities with Claude, Anthropic
• Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions, The Hacker News
• CVE-2026-98432 Kernel Flaw: Ubuntu, RHEL, Debian Status, PatchMon
• How to block the Linux TCP bug until Ubuntu and Red Hat ship a kernel, RFF
• CVE-2026-98432 status for CloudLinux, CloudLinux
• RFC 7126: Filtering of IPv4 Packets Containing IPv4 Options