Update on the Linux Kernel Flaw: Red Hat Has Fixed Kernels, Ubuntu's Are in Testing

Since our October 30 article on the flaw in the Linux kernel’s IPv4 TCP code (CVE-2026-98432), things have moved. Red Hat has shipped fixed kernels. Ubuntu has put its fixes in a testing channel. And one of the stopgaps in the October 30 article needs to be rewritten.

This article sets out what changed and what to check now, from each vendor’s own pages. The information is current as of November 6, 2026. The pages were updated on different days, so each statement carries its date.

Much of what circulates in secondary coverage differs from the original text. We read the primary sources ourselves, but we recommend that you check each vendor’s original page too.

Key points

• On November 1, Red Hat published fixed kernels for RHEL 8, 9 and 10 as advisories (RHSAs). A reboot is required (RHSA-2026:93414, 93412, 93413).
• On November 2, Canonical put fixes for Ubuntu 22.04, 24.04 and 26.04 in the testing channel (-proposed). They are not in regular updates yet. 20.04 and earlier are still waiting for a fix (Ubuntu).
• Turning off MPTCP is not enough. Red Hat calls it not a complete mitigation, and Ubuntu says the only appropriate mitigation is the security update (Red Hat, Ubuntu).
• Until you can patch, Red Hat published an nftables rule that drops inbound IPv4 TCP packets carrying IP options. It is not complete either (Red Hat).
• The flaw is still not in CISA’s Known Exploited Vulnerabilities (KEV) catalog (I checked the November 4 data directly). But a researcher has posted that he has seen internet-wide probing, since November 2, that he suspects is looking for this flaw. That is not a report of a successful attack.

What changed since October 30

We have updated the October 30 article’s MPTCP stopgap and its Red Hat entry to match this one.

Red Hat: fixed kernels are out

On November 1, Red Hat published fixed kernels for three RHEL versions.

All three include the fix for CVE-2026-98432. The RHEL 9 advisory also covers several extended-support streams (EUS and others). Check the advisory’s tables for the kernel number that matches your minor version (I could read only the first part of the RHEL 9 advisory).

The advisories’ severities do not match each other (Critical for RHEL 8, Important for 9 and 10). I could not confirm why.

One thing to watch is Red Hat’s other page. The security bulletin (RHSB-2026-016) was updated on November 4, but its text still says Red Hat is “expediting” fixes, and it lists no advisory numbers (Red Hat). The advisories exist and are dated November 1. I could not confirm why the two disagree. To find out whether a fix is out, use the individual advisory, not the bulletin.

The bulletin also says the following (Red Hat).

• MPTCP is disabled in RHEL’s default configuration. RHEL is still affected
• OpenShift Container Platform 4 (RHEL CoreOS) is affected. Products that use the RHEL kernel, such as OpenStack and virtualization, may also be affected
• kernel-rt (the real-time kernel) is not mentioned in the bulletin

Ubuntu: still in testing

Canonical wrote on November 2 that it has put fixes in the testing channel (-proposed) (Ubuntu).

Packages in -proposed are not installed by regular updates. You have to request them explicitly. No date is given for the move to regular updates. Canonical says it will wait until qualification testing across more than 2,000 certified servers and devices is done (Ubuntu). On Ubuntu’s tracking page, the cloud, FIPS and real-time kernels are also listed as work in progress (Ubuntu, updated November 5).

As of the October 30 article, every Ubuntu release was listed as vulnerable, with work in progress. That has moved forward.

Turning off MPTCP is not enough

In the October 30 article’s “stopgaps if you cannot update,” I listed “turn off MPTCP” first, on the grounds that it removes the premise of the demonstration. That was too weak a recommendation.

• Red Hat: turning off MPTCP is “not a complete mitigation.” It describes the MPTCP exploit as just one configuration in which exploitation has been demonstrated (Red Hat)
• Ubuntu: the fix is not specific to MPTCP. It says the advice to turn MPTCP off rests only on the demonstrated exploit having used MPTCP, and that the only appropriate mitigation is the security update (Ubuntu)
• Akamai (November 2): the flaw’s conditions are an IPv4 TCP listener, a SYN with IP options, and a retransmission. MPTCP is needed only for Anthropic’s reported exploit. Turning MPTCP off alone does not prevent exploitation; it only makes the race harder to trigger (Akamai)

Akamai names a second path too. A similar path exists when request-socket migration is enabled (net.ipv4.tcp_migrate_req=1, or a BPF program) (Akamai). Akamai did not test the attack itself; it relies on Anthropic’s description.

Turning MPTCP off is not pointless. It does remove the premise of the demonstration. But do not mark the server “handled” on that basis alone.

If you cannot patch yet: drop packets with IP options

As a measure until you install the fixed kernel, Red Hat published a configuration that drops inbound IPv4 TCP packets carrying IP options. Here it is, as in the original (Red Hat).

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

Save it as cve-2026-98432.nft, check the syntax with sudo nft --check --file cve-2026-98432.nft, and apply it with sudo nft --file cve-2026-98432.nft. After you install the fixed kernel, remove it with sudo nft delete table inet cve_2026_98432.

Red Hat itself notes the following (Red Hat).

• It is lost on reboot. If you reboot before installing the fixed kernel, apply it again
• It may drop traffic you need. Test it in a non-production environment first
• It is a mitigation, not a substitute for the fix
• On OpenShift it acts only on the node’s host traffic. Pod-to-pod traffic is not covered

A separate source, which is a personal blog and not an official guide, adds two cautions that Red Hat’s bulletin does not mention. Forwarded traffic is also affected, and the rule should not be used on CIPSO networks (labeled networks such as SELinux), where IP options are normal (RFF).

Ubuntu’s post on this flaw does not mention this rule. Ubuntu’s CVE page lists a similar workaround submitted by the community, with a note that it is not an official fix (Ubuntu).

What to do now

RHEL family (RHEL, AlmaLinux, Rocky Linux, Oracle Linux and others)

1. Update the internet-facing servers first. Run sudo dnf update kernel, then reboot
2. After the reboot, check with uname -r that the kernel is at or above the version in the table (check the advisory for the number that matches your minor version)
3. For compatible distributions such as AlmaLinux, Rocky Linux and Oracle Linux, check each vendor’s own notice (I have not checked their status directly)

Ubuntu

1. On 22.04, 24.04 and 26.04, a public-facing server that must be fixed right away can install from -proposed using Canonical’s procedure, which is in Canonical’s post. These are kernels still in testing, so try them in a test environment first, and do not leave -proposed enabled afterward (that last part is my advice)
2. If you cannot touch production right away, bridge the gap with the nftables rule above
3. 20.04 and earlier are waiting for a fix. Check Ubuntu’s CVE page regularly

On any distribution

• Updating is not enough. Reboot, then check uname -r. If you use live patching, confirm that it has been applied
• Containers use the host’s kernel. Updating the container image does not fix this
• Do not decide “we are fine, we have no MPTCP listener”

Has probing started?

Security researcher Marcus Hutchins posted the following observations on X on November 3 (X).

• Since November 2, residential proxies and Russian VPN servers have been probing port 443 with MPTCP connections
• Ordinary scanners do not use MPTCP, and no HTTP data is being sent. So he strongly suspects they are looking for this flaw (this is his inference)
• An internet-wide scan on October 30 found about 2.1 million servers reachable over MPTCP. That counts exposed servers, not unpatched kernels
• There is no public remote-code-execution exploit yet. Several denial-of-service proofs of concept are circulating

This post is not a report of a successful attack. It is an observation of probing, plus his inference. No raw logs or indicators of compromise (IOCs) accompany it. In what I searched, I could not find corroboration from other observers.

Other sources have not reported attacks yet. Akamai says it is not aware of a public working exploit (Akamai). The flaw is not in CISA’s KEV catalog (I checked the November 4 data directly).

How to read it: the probing report is one researcher’s account, with inference. But on systems like Ubuntu, where fixes are not yet in regular updates, “no attack has been confirmed, so it can wait” is hard to defend. For public-facing servers, move the measures above forward first.

What I could not confirm

• Whether the probing Hutchins saw is aimed at this flaw. It is his inference, and I found no corroboration from other organizations
• Anthropic’s exploit code is not public. Akamai also writes that it is not aware of a public working exploit (Akamai)
• The latter part of the RHEL 9 advisory (the details of each stream’s packages). For the RHEL 8 and 10 advisories I checked only the first part
• Why Red Hat’s advisories do not agree on severity
• Why the text of Red Hat’s security bulletin still says fixes are being expedited
• The fix status of RHEL-compatible distributions such as AlmaLinux, Rocky Linux and Oracle Linux
• When the Ubuntu fixes will move to regular updates

Related articles

• A Severity 9.8 Linux Kernel Flaw: What the AI-Built Attack Needs, and Where Each Distribution Stands: the October 30 article. How the flaw works, and what Anthropic’s demonstration showed
• Where PHP2Shell Reports and the Primary Sources Disagree: how headline numbers differed from the primary sources, and how to read numbers
• Two Critical GitLab Flaws, Not One: Why the October 12 Fix Is Not Enough: the severity 10.0 GitLab flaw from the same week. A fix that should have worked sometimes has not
• As Breaches Mount in Japan, What Leaders Should Decide First: Zero Trust and Security in the Age of AI: a way for executives to think about security in the age of AI
• The OpenSSH Flaw “*sshole”: Only Linux Systems Like Alpine Are Affected. How to Check and What to Do: the OpenSSH flaw from the same week. Only Linux on musl libc is affected

If you need help checking your servers’ kernels, planning updates and reboots, please contact us.