> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# CVE-2026-98432: Linux Kernel TCP Flaw Allows Remote Root Exploit

> A use-after-free in the Linux kernel's IPv4 TCP stack is exploitable remotely without authentication. Exposure, fixed kernels per distro, and mitigation.

*Published on November 14, 2026*

> [!WARNING]
>
> **CVE-2026-98432 — Linux kernel, IPv4 TCP connection setup.** The kernel security team scores this flaw 9.8. It is exploitable remotely, with no authentication, on any server that accepts IPv4 TCP connections. Install your distribution's fixed kernel and reboot today.

## The bug in two sentences

During a TCP handshake, the kernel hands the IP options of the connection request over to the new socket without copying them, then frees them without waiting for other CPUs to finish reading. A retransmitted SYN, handled at the same moment on another CPU, then builds its SYN-ACK from memory that has already been freed: a use-after-free in `ip_options_build()`.

A second path leads to the same bug: request socket migration (`net.ipv4.tcp_migrate_req=1` or a `BPF_SK_REUSEPORT_SELECT_OR_MIGRATE` BPF program).

Affected versions:

* **every Linux kernel since 4.4**;
* fixed upstream in **7.3-rc7**, and in stable branches **5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, and 7.2.10**.

The 9.8 score comes from the kernel CVE team and appears in the NVD record. Red Hat uses the same score and rates the flaw critical. Ubuntu gives it critical priority.

> [!NOTE]
>
> Anthropic described an exploit written by Claude, an unreleased internal research model: zero-click remote code execution as root on a server exposing a Multipath TCP (MPTCP) listener. The write-up describes the exploit without releasing its code. The flaw is not in CISA's Known Exploited Vulnerabilities (KEV) catalog (November 13, 2026 version).

## Sizing your exposure

The question to ask: **does your server accept IPv4 TCP connections?** Almost every server does: SSH, web, mail, databases.

MPTCP is not a precondition. The published exploit uses it, but Red Hat points out that the bug lives in plain IPv4 TCP: RHEL, which disables MPTCP by default, is still vulnerable.

| Profile | Exposure | Action |
| - | - | - |
| Server accepting IPv4 TCP from the Internet (SSH, web, mail) | **Critical** | Fixed kernel and reboot today; nftables rule in the meantime |
| Server with an MPTCP listener (Go 1.24 and later programs, by default) | **Critical**, the published exploit's setup | Same action, right away |
| Server reachable from an internal network only | High | Update promptly |
| Kubernetes node or container host | **Critical** | Update every node's kernel; the nftables rule does not filter pod-to-pod traffic |
| RHEL 6 and 7 | Not affected, per Red Hat | Nothing to do |

To see the running kernel:

```bash theme={null}
# Any distribution: version of the loaded kernel
uname -r

# Debian: the package version is shown in uname -v
uname -v
```

> [!NOTE]
>
> Disabling MPTCP (`sysctl -w net.mptcp.enabled=0`) does not protect you: it closes the demonstrated setup, not the flaw. Likewise, `ss -Mlnp` shows whether a service listens over MPTCP, but an empty result does not mean the server is safe. The Go security team gives the same warning: since Go 1.24, Go programs open their listening sockets with MPTCP by default on Linux, and only a kernel update solves the problem.

## Updating the kernel, distro by distro

The fix is a kernel update followed by a **reboot**. Until the server reboots, the old kernel stays loaded and the flaw stays open.

Before rebooting a production VPS, take a [snapshot](https://help.onetsolutions.net/vps/snapshot). If the server does not come back on the network, the [KVM console](https://help.onetsolutions.net/vps/kvm-console) gives you the boot screen.

### Debian

| Version | Fixed package | Advisory |
| - | - | - |
| Debian 13 (trixie) | `linux` `6.12.113-1` or later | DSA-6568-1 |
| Debian 12 (bookworm) | `linux` `6.1.190-1` | DLA-4841-1 |
| Debian 12, backported `linux-6.12` kernel | `6.12.113-1~deb12u1` or later | DLA-4850-1 |

```bash theme={null}
# Debian: install the fixed kernel, then reboot
sudo apt update
sudo apt full-upgrade
sudo reboot

# After the reboot: the package version is shown in the output
uname -v
```

### Ubuntu

| Version | Fixed `linux` kernel |
| - | - |
| 26.10 | `7.3.0-10.10` |
| 26.04 LTS | `7.0.0-43.43` |
| 24.04 LTS | `6.8.0-149.149` (HWE kernel: `7.0.0-43.43~24.04.1`) |
| 22.04 LTS | `5.15.0-203.213` (HWE kernel: `6.8.0-149.149~22.04.1`) |

Specialized kernels (cloud, lowlatency, FIPS) have their own versions: see [Ubuntu's CVE page](https://ubuntu.com/security/CVE-2026-98432).

```bash theme={null}
# Ubuntu: install the fixed kernel, then reboot
sudo apt update
sudo apt full-upgrade
sudo reboot

# After the reboot, for example 6.8.0-149-generic on 24.04
uname -r
```

### RHEL, AlmaLinux, Rocky Linux

| Version | Fixed kernel | Red Hat advisory |
| - | - | - |
| RHEL 10.2, AlmaLinux 10 | `kernel-6.12.0-211.72.1.el10_2` | RHSA-2026:93413 |
| RHEL 10.3 | `kernel-6.12.0-264.14.1.el10_3` | RHSA-2026:98608 |
| RHEL 9, AlmaLinux 9 | `kernel-5.14.0-687.64.1.el9_8` | RHSA-2026:93412 |
| RHEL 8, AlmaLinux 8 | `kernel-4.18.0-553.182.1.el8_10` | RHSA-2026:93414 |

The AlmaLinux versions come from AlmaLinux's advisory. For Rocky Linux and RHEL EUS releases, check [Red Hat bulletin RHSB-2026-016](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) and your distribution's advisory.

```bash theme={null}
# RHEL, AlmaLinux, Rocky Linux: install the fixed kernel, then reboot
sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

# After the reboot: loaded kernel and installed kernels
uname -r
rpm -q kernel
```

### Kubernetes

Every node needs the fixed kernel and a reboot. Drain nodes one at a time to keep the service up:

```bash theme={null}
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# on the node: kernel update and reboot, as above
kubectl uncordon <node>
```

Red Hat notes that an nftables rule on a node only filters traffic that crosses the host's network namespace, not pod-to-pod traffic. Filtering at the network edge, in front of the cluster, has no such gap.

## Mitigation until you can patch

Red Hat and Ubuntu publish the same nftables rule: it drops inbound IPv4 TCP packets that carry IP options, which removes the input the flaw needs. Standard TCP options (timestamps, window scaling) still pass, and so does IPv6. The rule takes effect without restarting services.

Its limits:

* it **reduces the risk without removing it** and does not replace the kernel update;
* it breaks connections that depend on IPv4 options;
* it covers the host; a container with its own networking needs the rule applied separately, and traffic between containers on the same host can bypass it;
* test it against your own traffic before rolling it out to production.

### Debian and Ubuntu

Procedure published by Ubuntu. It assumes the firewall is managed through `/etc/nftables.conf`, without UFW or firewalld; Debian uses the same file.

```bash theme={null}
# 1. Create the rule file
printf '%s\n' 'table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}' | sudo tee /etc/cve-2026-98432.nft >/dev/null

# 2. Check, then apply the rule
sudo nft -c -f /etc/cve-2026-98432.nft &&
sudo nft -f /etc/cve-2026-98432.nft

# 3. Keep the rule across reboots (run once)
echo 'include "/etc/cve-2026-98432.nft"' | \
  sudo tee -a /etc/nftables.conf
sudo nft -c -f /etc/nftables.conf &&
sudo systemctl enable nftables.service
```

### RHEL, AlmaLinux, Rocky Linux

Procedure published by Red Hat. Save the rule to a file named `cve-2026-98432.nft`:

```text theme={null}
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
```

Then check and apply it:

```bash theme={null}
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432
```

This rule does not survive a reboot. To make it persistent, follow the "Making the mitigation persistent" section of [bulletin RHSB-2026-016](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016): Red Hat warns that enabling `nftables.service` may conflict with firewalld or an existing configuration.

## Verifying the mitigation

```bash theme={null}
sudo nft list table inet cve_2026_98432
```

The command should print the table and its `input` chain. The counter on the `drop` line shows how many packets were dropped. An error means the rule is not loaded.

## Rolling back the mitigation

Once the fixed kernel is loaded (check with `uname -r` or `uname -v`), remove the rule.

```bash theme={null}
# Debian, Ubuntu: remove the rule and its boot-time include
sudo sed -i '\|^include "/etc/cve-2026-98432.nft"$|d' \
  /etc/nftables.conf
sudo nft delete table inet cve_2026_98432

# RHEL, AlmaLinux, Rocky Linux (non-persistent rule)
sudo nft delete table inet cve_2026_98432
```

If you made the rule persistent on RHEL, follow the "Reverting After Patching" section of the Red Hat bulletin.

## What next?

The nftables rule is only a stopgap: the target is the fixed kernel, loaded after a reboot. For another recent Linux kernel flaw, read [Copy Fail (CVE-2026-31431)](https://blog.onetsolutions.net/en/copy-fail-cve-2026-31431.md). For any technical question, open a ticket from your [OnetSolutions customer area](https://help.onetsolutions.net/console/support).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.