CVE-2026-98432 patch: four clocks from kernel fix to your server
The CVE-2026-98432 patch reached Debian in a day and RHEL in 17 days; Ubuntu's is in -updates with no notice yet. The four clocks and what to do by when.
CVE-2026-98432 is a use-after-free in the Linux kernel’s IPv4 TCP connection handling that an unauthenticated peer can trigger over the network; fixed stable kernels were out by 15 October 2026, the day the CVE was published. The CVE-2026-98432 patch reached Debian on 16 October and Red Hat on 1 November, and Ubuntu’s fixed kernels for 22.04, 24.04 and 26.04 entered its -updates pocket on 5 and 6 November, with no Ubuntu Security Notice as of 7 November 2026. A server is protected only once it runs a fixed kernel, so its exposure depends on four separate clocks, and a vulnerability scanner reads only some of them.
This post covers the flaw and the dispute over its exploit, how each clock ran for this CVE, how to check a server, a dated plan, and what the OpenSSH fix of 5 November shows by contrast.
What is CVE-2026-98432, and how severe is it?
The CVE record describes a race in the IPv4 TCP handshake: while one CPU answers a retransmitted SYN, another can free the IP options that answer is built from, “leading to a use-after-free in ip_options_build()”. Kernels from 4.4 onwards are affected, and IPv6 is not affected by the first issue. The fix, committed on 5 October 2026, frees those options only after an RCU grace period.
Who found it. The fix credits a report by Xinyang Ge of Anthropic. On 27 October, Anthropic’s Frontier Red Team wrote that it had used “an unreleased, internal research model”, and that “Claude wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root, without any credentials or user interaction”. Anthropic has not published the exploit.
What is disputed. Remote root is the finder’s claim. CloudLinux says “Our kernel team couldn’t reproduce the claim.”
What is not disputed. Red Hat rates the flaw Critical because a remote attacker can “cause kernel memory corruption or an immediate system crash”, while noting that reliable code execution “requires precise heap control”. Multipath TCP (MPTCP) is where the claimed exploit runs, not where the bug lives. Red Hat’s bulletin RHSB-2026-016 says: “Having MPTCP enabled is not a precondition of this vulnerability.” Canonical says “the CVE fix is not specific to MPTCP”, and CloudLinux that “the bug itself is in ordinary TCP code”. Turning MPTCP off is not a fix.
Exploitation. As of 7 November 2026, CVE-2026-98432 is not in CISA’s Known Exploited Vulnerabilities catalogue (version of 6 November), and CloudLinux wrote on 3 November that “no exploitation in the wild has been reported”. Anthropic notes that a lost race only fails one handshake, so “a determined attacker can retry indefinitely”. Absence from the catalogue is a reason to keep watching, not to wait.
When did Debian, Red Hat and Ubuntu ship the CVE-2026-98432 patch?
Day 0 is 15 October 2026, when the CVE was published.
| Date (2026) | Clock | What happened | Day |
|---|---|---|---|
| 5 October | Commit | Fix committed to the kernel’s networking tree | Before |
| 11 October | Commit | Fixed stable kernels 6.18.56 and 7.2.10 | Before |
| 15 October | Commit and record | Fixed stable kernels 6.12.113, 6.6.159, 6.1.190, 5.15.223 and 5.10.272; CVE published the same day, with no CVSS score | 0 |
| 16 October | Package | Debian 13: DSA-6568-1, linux 6.12.113-1 | 1 |
| 17 October | Package | Debian 12 (LTS): DLA-4841-1, linux 6.1.190-1 | 2 |
| 24 October | Score | The kernel’s CVE team adds a CVSS 3.1 score of 9.8 | 9 |
| 26 October | Package | Ubuntu 22.04 and 24.04: fixed kernels in -proposed | 11 |
| 27 October | Claim | Anthropic publishes its remote-root claim | 12 |
| 28 October | Package | Ubuntu 26.04: fixed kernel in -proposed | 13 |
| 30 October | Package | AlmaLinux 8, 9 and 10: its own backport, in its testing repository | 15 |
| 1 November | Package | RHEL 8, 9 and 10: kernel errata | 17 |
| 2 November | Running | CloudLinux livepatch for CloudLinux 7h, 8 and 9 (10 followed on 3 November) | 18 |
| 5 and 6 November | Package | Ubuntu 22.04, 24.04 and 26.04: fixed kernels in -updates (Launchpad) | 21 and 22 |
| 7 November | Package | No Ubuntu Security Notice; fix not yet in Ubuntu’s -security pocket | 23 |
The four clocks behind a kernel fix
The commit: when the fix is public
A kernel fix is public once it is committed. Here every maintained stable branch had a fixed release by 15 October, the day the CVE was published. A public commit helps defenders and attackers alike, since anyone can read what changed. It also lets anyone build the fix: AlmaLinux backported it from the stable kernels and offered it for testing on 30 October, when, in its words, “no fixed RHEL kernel is available”.
The score: when dashboards start to care
For nine days the CVE record carried no score. The 9.8 now attached to it was added on 24 October by the kernel’s own CVE team, according to the change history on NVD, which lists the CVE as “Awaiting Analysis” as of 7 November. Vendors differ: Red Hat and Ubuntu rate it Critical at 9.8, while SUSE scores it 8.1 because it rates the attack complexity high.
The flaw also arrived in a crowd. Debian’s advisory of 16 October lists 273 CVE IDs, and Canonical notes that the kernel community, as its own CVE Numbering Authority, “assigned CVE (Common Vulnerabilities and Exposures) identifiers to thousands of bugs”. A dashboard that ranks by the record’s score had nothing to rank this one by until day nine.
The package: when your distribution ships it
Distributions take different routes. Debian ships stable kernel releases as batch updates; DSA-6568-1 moved Debian 13 to 6.12.113 the day after the CVE. Red Hat backports fixes into its own long-lived kernels. Canonical tests each kernel before it leaves the -proposed pocket: on 23 September it explained that “Expedited releases aren’t possible while thoroughly testing every release candidate”, and pointed users who need speed to -proposed for their own acceptance tests. On 2 November it wrote that “we perform extensive tests on more than 2,000 certified servers and devices”. That is a deliberate trade of speed against regression risk, and Canonical states it openly.
As of 7 November 2026, three facts describe the Ubuntu fix for 22.04, 24.04 and 26.04:
- It is in -updates, so a manual upgrade from the default archive installs it.
- It is not yet in -security, the pocket that unattended-upgrades installs from by default; -updates is commented out of its default configuration (Ubuntu Server documentation). A server left on automatic security updates has not received it.
- No notice covers it. Ubuntu’s CVE page lists these releases as “Vulnerable work in progress in” the versions now in -updates, its status until a notice is published; compare the installed package with that number.
Ubuntu 16.04 to 20.04 are past standard support and covered through Ubuntu Pro’s Expanded Security Maintenance (16.04 with the Legacy add-on); as of 7 November their kernels are also listed as “work in progress”.
The reboot or livepatch: when the running kernel changes
Installing a kernel package changes the disk, not the running system. Canonical’s post says: “Once the security updates for the Linux kernel are installed, a reboot is required”. Ubuntu’s unattended-upgrades does not reboot by default; its Automatic-Reboot setting defaults to false. The alternative is a livepatch, which changes the running kernel in place, as CloudLinux’s KernelCare did from 2 November. Whether one exists depends on the vendor, the exact kernel build and the subscription.
No public record shows this clock; each operator reads it for its own machines. It is the kernel version of a lesson from PHP2Shell and the eMudhra trust stores: an installed fix is not yet a running one.
How do you check a server for CVE-2026-98432?
Compare the running kernel with your distribution’s fixed version, not with the upstream number, because distributions backport.
| Distribution | Fixed kernel package | Advisory |
|---|---|---|
| Debian 13 (trixie) | linux 6.12.113-1 | DSA-6568-1 |
| Debian 12 (bookworm, LTS) | linux 6.1.190-1 | DLA-4841-1 |
| RHEL 10 | kernel-6.12.0-211.72.1.el10_2 | RHSA-2026:93413 |
| RHEL 9 | kernel-5.14.0-687.64.1.el9_8 | RHSA-2026:93412 |
| RHEL 8 | kernel-4.18.0-553.182.1.el8_10 | RHSA-2026:93414 |
| Ubuntu 26.04 LTS | linux 7.0.0-43.43 | None yet; in -updates |
| Ubuntu 24.04 LTS | linux 6.8.0-149.149 | None yet; in -updates |
| Ubuntu 22.04 LTS | linux 5.15.0-203.213 | None yet; in -updates |
Cloud, hardware-enablement and real-time kernels have their own versions on each vendor’s page.
- Read the running kernel, not the installed one.
uname -rshows the kernel in memory; on Ubuntu it prints the ABI number, such as 6.8.0-149-generic for 6.8.0-149.149. A newer installed kernel means a pending reboot: Ubuntu creates /var/run/reboot-required, and on RHELdnf needs-restarting -rsays so. - Search Ubuntu changelogs for the fix, not the CVE. The changelogs of the three fixed Ubuntu kernels list it under its commit title, “ipv4: free inet_opt and ireq_opt after an RCU grace period”, and do not mention CVE-2026-98432.
- Check livepatched hosts with the livepatch tool’s own status, not the kernel package version, which a livepatch does not change.
- Count container hosts, not images. Containers share the host’s kernel, so rebuilding an image changes nothing here. The nftables rule in step 3 must also be applied separately to containers with their own networking.
What to do, and by when
These dates are our suggestion. No legal deadline applies.
- By 9 November 2026: list every Linux machine and its running kernel. Include virtual machines, container hosts and appliances, and record distribution, release, running kernel, installed kernel and last reboot. Start with machines that accept connections from the internet.
- By 11 November 2026: on Debian, RHEL and its rebuilds, install the fixed kernel and reboot into it, or apply your vendor’s livepatch and confirm that it is active. These fixes have been available since 16 and 17 October (Debian) and 1 November (RHEL).
- By 11 November 2026: on Ubuntu 22.04, 24.04 and 26.04, decide whether to take the -updates kernel now. It carries the version Ubuntu’s CVE page names for the fix. If you take it, test, reboot and record. If you wait for the notice, apply the nftables rule on the CVE page, which drops inbound IPv4 TCP packets that carry IP options; the page says it “reduces the risk but does not fully prevent exploitation”, and Red Hat that filtering “is not a substitute for patching”.
- Now, for Ubuntu 16.04 to 20.04: confirm your Ubuntu Pro coverage and apply the nftables rule from step 3, since the CVE page lists no released fix for these releases as of 7 November; then set a date to leave every release that is past standard support.
- Do not record an MPTCP setting as the fix. The bug sits in ordinary TCP code.
- From the next maintenance cycle: set a target for each clock. Watch your distribution’s tracker directly as well as the scanner, set the maximum days from distribution package to running kernel by exposure, and write that target and who approves reboots into your supplier and operator contracts. Our CRA supplier questions give the wider list.
Open source shows every clock. Someone has to watch them
Every date in this post comes from a public record. The fair comparison with a proprietary operating system runs from the vendor being notified to a fix being available, not from a public commit to a package, and nothing here shows that either model is faster. What open source adds is that anyone can measure each interval, and that more than one party can close it: Debian in a day, AlmaLinux with its own backport, Canonical with a candidate build in -proposed. The commit is public for attackers too, which is why the later clocks matter.
The clocks also differ by project. On 5 November, OpenSSH 10.6p2 shipped a workaround for a password authentication bypass on Linux systems that use musl without PAM, CVE-2026-123158; Damien Miller wrote “we learned of the problem yesterday”. There the upstream clock ran one day; for CVE-2026-98432, the package and reboot clocks ran longest. Alpine’s advisory says systems with password authentication turned off in sshd are not affected. No setting does that for CVE-2026-98432.
Public dates do not move a kernel on their own. Four practices do:
- An inventory of running kernels, not of installed packages.
- Distribution trackers watched directly, not only the scanner’s score.
- A patch pipeline that ends with a reboot or a verified livepatch, with the time recorded.
- Fewer ports within reach of the internet, which narrows exposure while a fix is pending without replacing it.
How Pilae fits
Watching four clocks on every machine is operating work. Pilae operates open-source apps on your premises or on dedicated machines in Pilae Cloud. On premises, from the Business plan, Pilae runs everything from the operating system up; in Pilae Cloud, the whole stack. Plans are on the pricing page.
- The operating system on our side of the line. In the responsibility matrix annexed to your contract, the operating system and its hardening sit with Pilae in both models, and security fixes are planned and applied by Pilae after your approval.
- Hardened machines. Each machine has a minimal operating system, closed ports, key-only SSH and a host firewall.
- One gate to the internet. Apps answer only on the private network, host firewalls close every public port, and the internet reaches one hardened gate on port 443. That narrows who can open a connection to your machines; it does not replace a fix.
- Every machine on one screen, every change on record. The console shows every machine on your premises or in Pilae Cloud, with its region, size, operating system and live metrics, and every login, approval, command and configuration change goes to the audit log, exportable to your SIEM.
Who watches each clock, and who approves the reboot, is better settled in writing before the next kernel flaw than during it. To see where each clock stands for the machines you run, talk to an engineer: we go through your servers, the distributions and kernels under your apps, and who is responsible for each layer.