CVE-2026-98432: The Linux IPv4 TCP Use-After-Free That Vendors Scored From 5.9 to 9.8

Executive Summary

CVE-2026-98432 is a use-after-free in the Linux kernel’s IPv4 TCP handshake code. It is reachable across the network, before any application authentication, on any host with a listening IPv4 TCP port. The flaw has been present since Linux 4.4, so it reaches effectively every maintained distribution kernel. An attacker who wins a race condition during connection setup can read freed kernel memory and, under the right conditions, corrupt kernel control flow. Anthropic’s Frontier Red Team reported that an internal research model built a working exploit that defeated KASLR and ran commands as root on a server with a Multipath TCP (MPTCP) listener, with no credentials and no user interaction.

The operational story here is not the bug itself. It is the scoring. For roughly two weeks, the same CVE carried a different CVSS score depending on which vendor feed you read. The Linux kernel CNA scored it 9.8 Critical with a written exploitability scenario. Red Hat first published 5.9 Moderate, called a kernel crash the likely worst case, and deferred the fix. Over the next fifteen days Red Hat moved to 8.1, then to 9.8 Critical, and shipped patched RHEL kernels. SUSE, Oracle, and Amazon settled at 8.1. Amazon itself started at 7.0 before raising to 8.1. None of these revisions followed a change in the code. They followed the appearance of a credible exploit.

For any team that keys patch SLAs off a numeric threshold, this CVE is a live example of why a vendor base score is an opinion about exploitability rather than a measurement of it. The same flaw that one feed flagged for emergency patching, another parked as a deferred denial-of-service issue. The code was identical in both cases.

TL;DR for Engineering Teams

What it is: CVE-2026-98432, a use-after-free in the Linux kernel IPv4 TCP connection-request path (CWE-825). CVSS 3.1 9.8 from the kernel CNA, Ubuntu, and now Red Hat; 8.1 from SUSE, Oracle, and Amazon.

Where it bites: Any Linux host (kernel 4.4 and later) with a reachable IPv4 TCP listener. Servers running MPTCP listeners are the demonstrated remote-root path. Go 1.24 and later open MPTCP listeners by default on supported kernels, so Go network services can expose this surface without operators knowing.

Why it matters: Network-reachable, pre-authentication, no user interaction. A lost race costs the attacker nothing and does not crash the host, so attempts can repeat indefinitely. Public trigger and PoC code is multiplying. No confirmed exploitation in the wild, and the CVE is not in CISA KEV as of November 5, 2026.

Patch status: Partial. Fixed: RHEL 8/9/10, AlmaLinux 8/9/10, Debian 12/13, Oracle UEK, Amazon Linux 2 and 2023, SLES 15 SP4 to SP7, and SLES/openSUSE Leap 16.0. In testing: Ubuntu 22.04 and newer, with fixed kernels in the -proposed pocket since November 2. Still unpatched: Ubuntu 20.04 and older, OpenShift 4 (RHCOS), RHEL 9 real-time, SLE Real Time 15 SP7, and Rocky Linux community builds.

Immediate action: Patch the kernel and reboot, then confirm the running version with uname -r. Where no fixed kernel exists yet, drop inbound IPv4 TCP packets that carry IP options. Disabling MPTCP alone is not sufficient, because the bug is also reachable over ordinary TCP.

Vulnerability Overview

One Bug, Five Scores: The CVSS Problem in Plain View

The scoring spread is the reason this CVE is worth studying beyond its own patch cycle. Below is where each source landed, as of November 2, 2026.

Two judgment calls produced the entire spread, and both are baked into the CVSS base vector.

The first is Attack Complexity. Vendors who scored AC:H treat winning a cross-CPU race against connection teardown as a condition outside the attacker’s control. The kernel CNA took the opposite view and wrote it down: the attacker drives both sides of the race by creating option-bearing requests and racing a retransmitted SYN against teardown, and multicore scheduling or heap grooming do not count as conditions beyond the attacker’s influence. Anthropic’s report backs the CNA reading in practice. A lost race only fails that one handshake and does not crash the server, so an attacker can retry until it works. A race you can retry for free is a cost-of-time problem, not a complexity barrier. Flipping AC from Low to High on its own drops the score from 9.8 to 8.1.

The second is worst-case impact. Red Hat’s original 5.9 scored availability only, on the premise that no confidentiality or integrity impact had been shown, and described the practical outcome as a kernel crash. Once Anthropic demonstrated an information leak that defeats KASLR and a control-flow hijack to root, C:N/I:N was no longer defensible. Restoring high confidentiality and integrity impact is what moved Red Hat’s interim score to 8.1. Adding the Low attack complexity on top is what took it to 9.8.

The timeline is worth keeping for the postmortem. The kernel CNA published the CVE on October 15 without a score, then added 9.8 with its scenario on October 24. Red Hat’s 5.9 Moderate appeared on October 17 with the fix deferred. Anthropic published its exploit description on October 27. Within two days Red Hat’s machine-readable data moved to 8.1 while its human-readable CVE page still showed 5.9, so for about a day the vendor published two different scores for the same flaw. By October 30 the page showed 8.1 and Red Hat issued security bulletin RHSB-2026-016 rated Critical. Amazon raised 7.0 to 8.1 on October 31. By November 1 Red Hat’s page showed 9.8 Critical and fixed RHEL kernels shipped the same day.

One point of context on kernel scoring. The kernel CNA historically issued CVEs without CVSS at all, on the argument that severity depends on each user’s configuration, and it issues them at very high volume. Phoronix reported Greg Kroah-Hartman’s Kernel Recipes 2026 figures showing recent releases exceeding a thousand CVEs each. A CNA-supplied 9.8 with a written exploitability argument is therefore the exception, not the norm, which is a signal in itself: the kernel team chose to make the case for severity here rather than leave it to downstreams.

Technical Anatomy

Root Cause

The primary defect lives in tcp_v4_syn_recv_sock(). When a server completes the TCP handshake, this function transfers ownership of the pending request socket’s IP options (ireq->ireq_opt) to the new child socket (newinet->inet_opt). It hands over the original rather than a copy, so two objects briefly reference the same heap allocation.

The kernel processes pending connection requests without holding the listener lock. A second CPU can therefore be answering a retransmitted SYN for the same request socket, sending a SYNACK through tcp_check_req(), while the first CPU completes and tears down the new socket. On the send path, tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() then has ip_options_build() read opt->optlen twice. Because TCP child sockets did not carry SOCK_RCU_FREE and inet_sock_destruct() freed inet_opt with a plain kfree(), the second CPU can read memory the first CPU has already released. The result is a use-after-free in ip_options_build(). The behavior dates back to the Linux 4.4 change that installed SYN-RECV requests into the ehash table and began processing them lockless.

A second route to the same bug exists during request socket migration, enabled by net.ipv4.tcp_migrate_req (off by default) or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. The timer handler clones the request socket so the original and the clone share ireq_opt, and tcp_v4_reqsk_destructor() also used a plain kfree().

IPv6 is not affected by the main race, because its equivalent function duplicates the options rather than transferring them.

Exploit Path

1. Entry point. The attacker sends a TCP SYN carrying IPv4 options (Record Route or Timestamp) to a listening IPv4 port, then retransmits it to drive the race. No credentials, no session, no prior access.
2. Trigger. Two CPUs act on the same request socket at once. One completes and frees the connection while the other reads the now-stale ireq_opt and its length field during SYNACK construction. The freed optlen governs how much memory ip_options_build() reads or writes.
3. Execution impact. A stale length drives an out-of-bounds read that copies adjacent kernel heap bytes back to the attacker, which leaks a kernel pointer and defeats KASLR. The same primitive supports an out-of-bounds write that can overwrite a callback pointer, redirecting kernel control flow to a payload staged through an ordinary protocol feature. In Anthropic’s demonstration this reached a root shell.

Fix

The upstream fix is commit e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”), authored by Eric Dumazet and crediting Anthropic’s Xinyang Ge as reporter. It switches inet_sock_destruct() and tcp_v4_reqsk_destructor() to kfree_rcu(), so concurrent RCU readers finish before the options are released, and it closes the migration path at the same time.

Affected Versions

Exposure Analysis

The exposure that catches teams off guard is MPTCP by default. Go 1.24 changed ListenConfig to use MPTCP by default on Linux where the kernel supports it, so any Go 1.24 or later service calling net.Listen opens an MPTCP listener unless it opts out. Whether the kernel permits it varies: CIQ found net.mptcp.enabled=0 by default on the RHEL-family kernels it tested, while Debian 12 was observed with it enabled. The Go Security Team’s framing is the one to carry to stakeholders: the demonstrated exploit needs an MPTCP listener, but the underlying bug is not specific to MPTCP, and systems with no MPTCP listener may be vulnerable to similar attacks over ordinary TCP. No reliable public count of internet-facing MPTCP listeners exists, so treat any specific exposed-host figure with caution.

Real-World Impact

Anthropic’s post, “Discovering and exploiting vulnerabilities in critical, real-world software with Claude” (October 27, 2026), states that an unreleased internal research model, after initial prompting, wrote an exploit that sent packets to a Linux server with an MPTCP listener and ran arbitrary commands as root without credentials or user interaction. The run took about 48 minutes to leak a kernel pointer and five more to reach command execution, roughly 53 minutes end to end.

Three limits matter for how teams communicate this. Anthropic has not released exploit code, and has not published the kernel version or configuration tested, why the chain targets MPTCP listeners, or whether non-MPTCP servers fall the same way. The claim has not been independently verified at the remote-code-execution level. What is verified is the bug and the primitive: public research confirms the use-after-free and reproduces it. Innora published a QEMU-based reproduction on an instrumented 6.12 kernel and marked the full chain verified in its lab, while stating it would not release a weaponized exploit in the short term. Other public repositories provide KASAN-confirmed UAF reproductions and proof-only race triggers that detect freed bytes echoed in SYNACKs. None is a public RCE chain. One PoC author notes that short runs produced no hits, so a quick negative test is not evidence that a host is safe.

Scale comes from reach rather than a single telemetry number. The defect sits in code common to nearly all networked Linux services and present since kernel 4.4. Red Hat’s own bulletin notes that because TCP underpins almost all networked services, the affected surface is broad.

Detection Guidance

Kernel-version detection is the primary signal, and it has a trap: compare the running kernel, not the installed package, against the fixed build for your distribution. A patched package does nothing until the host reboots into it. On RPM systems, these two commands confirm whether the active kernel carries the fix:

shell

uname -r
rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

For attack-surface detection, enumerate MPTCP listeners with ss -Mltn on recent kernels, and on older RHEL 8 kernels fall back to sysctl net.mptcp.enabled. Inventory Go binaries built with 1.24 or later that do not opt out of MPTCP; go version -m <binary> exposes the Go version and any godebug multipathtcp setting in the build info.

Network indicators focus on the trigger. Inbound SYNs with an IPv4 header length above 20 bytes (IHL greater than 5), especially carrying Record Route or Timestamp options, and repeated retransmitted SYNs from the same peer, are the on-the-wire markers. A capture filter such as the one below surfaces them:

shell

tcp[tcpflags] & tcp-syn != 0 and ip[0] & 0xf > 5

The nftables counter used in the mitigation rule below doubles as a passive sensor. On the host side, oops or panic traces mentioning ip_options_build, ip_build_and_send_pkt, or skb_under_panic on internet-facing systems are worth alerting on, with the caveat that a lost race does not crash the host, so clean logs are not proof of safety. No vendor has published IOCs or an ATT&CK mapping for this CVE.

Scanner coverage: Phoenix Security and standard SCA tooling will flag the kernel package version, but package-level results need pairing with running-kernel and reboot state to avoid false clears. External attack-surface scanning should prioritize internet-facing IPv4 TCP listeners and identified MPTCP endpoints.

Remediation Guidance

Immediate Actions

1. Patch the kernel and reboot where a fixed build exists for your distribution (see the Affected Versions table). This is the only complete fix. Validate with uname -r against the fixed version, and remove any interim firewall rules only after the reboot is confirmed.
2. For hosts with no production fix yet (Ubuntu until the -proposed kernels reach updates, OpenShift 4, RHEL 9 real-time, SLE Real Time 15 SP7, Rocky community), stage the kernel update and a reboot window now, and apply the packet-level mitigation below in the meantime. Ubuntu 22.04 and newer users who run their own kernel acceptance tests can install the -proposed kernels now.
3. Confirm managed-service posture. AWS shipped patched Fargate, ECS, and RDS/Aurora builds; verify your platform versions and do not expose database ports to the internet.

Temporary Mitigations

Drop inbound IPv4 TCP packets that carry IP options, which removes the trigger. Red Hat’s RHSB-2026-016 uses an input hook that drops TCP packets whose IP header length exceeds 5 words. CIQ publishes a persistent nftables unit using a prerouting hook:

nft

table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        ip hdrlength gt 5 meta l4proto tcp counter drop
    }
}

Few legitimate internet services require inbound IP options, but test before deploying. CIQ confirmed this also blocks the syncookie ACK path, and warns it did not test IPv6, fragments, or forwarded and container traffic, and that stopping nftables.service flushes the table.

Disabling MPTCP is not a substitute. CIQ verified that with net.mptcp.enabled=0, a plain TCP listener still answered a SYN carrying Record Route and echoed the option. Turning MPTCP off (via sysctl, or GODEBUG=multipathtcp=0 / a godebug multipathtcp=0 line in go.mod for Go services) narrows the demonstrated path only.

Keep net.ipv4.tcp_migrate_req=0 and audit for BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programs to close the second route. Where feasible, restrict inbound IPv4 TCP to trusted networks, and note that terminating TCP at a load balancer that originates fresh connections to backends keeps attacker-crafted SYN options from reaching the host.

Phoenix Security Recommendations

A CVE whose score moved from 5.9 to 9.8 in two weeks is exactly the case where feed-driven prioritization fails quietly, so the platform guidance centers on not trusting a single number.

Evidence-based scoring with Phoenix Blue. The spread on this CVE comes from vendors reading the same vector differently. Phoenix Blue separates two questions the base score blends together: how bad the flaw can be, and how much attacker evidence exists right now. Its threat-centric model weights exploitation evidence (CISA and VulnCheck KEV, mass-scan telemetry, ransomware links), blast radius, likelihood and speed pressure, and the result updates as that evidence changes, not when a vendor revisits its vector. Its exploitation tiers run from Tier 1 Confirmed through Tier 2 Likely to Tier 3 Emerging. On November 5, 2026, Phoenix Blue shows CVE-2026-98432 at CVSS 9.8 Critical and Tier 3 Emerging: maximum theoretical severity, but no confirmed exploitation and no KEV listing yet. That is the honest read for this bug. Patch now on the strength of the CVSS case, and set an alert in Phoenix Blue so the move to Likely or Confirmed reaches you the day exploitation evidence lands. Phoenix Blue is free and open to everyone at phxintel.security.

Contextual deduplication folds the kernel finding from every scanner, across every host and image, into one prioritized item, so a feed that still carries Red Hat’s stale 5.9 or Amazon’s old 7.0 does not fragment the backlog or hide the true severity. Pin CVE-2026-98432 to critical and prevent a feed refresh from downgrading it.

Reachability analysis separates hosts with a reachable IPv4 TCP listener, and in particular an MPTCP listener, from the rest of the kernel-vulnerable fleet, so remediation effort lands on the exposed surface first rather than on every box that merely runs an old kernel.

Remediation campaigns turn the split patch picture into owned work: create a campaign, assign owners by host and service, track the reboot-into-fixed-kernel step rather than only the package upgrade, and verify runtime exposure afterward. Because a patched package is inert until reboot, the campaign’s completion gate should be the running kernel version, not the installed one.

Vulnerability ownership attribution maps each affected host and service to the responsible team automatically, so the mixed estate of patched RHEL, pending Ubuntu, and Go services with hidden MPTCP listeners resolves into named owners instead of an unassigned queue.

Attack surface management identifies the internet-exposed services running vulnerable kernels and MPTCP listeners, which is where the demonstrated remote-root path actually applies, and keeps that list current as kernels get patched and rebooted.

Protect yourself with the latest threat intelligence, get free access to Phoenix Blue Today

External References

Vulnerability records

1. Linux kernel CNA, CVE-2026-98432 announcement: git.kernel.org · linux-cve-announce mirror
2. CVE record: cve.org record
3. NVD entry: NVD entry
4. Upstream fix, commit e3f33b0a1d89, “ipv4: free inet_opt and ireq_opt after an RCU grace period” (Eric Dumazet; reporter Xinyang Ge): git.kernel.org/linus/e3f33b0a1d89

Vendor advisories

5. Red Hat, CVE-2026-98432: Red Hat CVE page
6. Red Hat Security Bulletin RHSB-2026-016: access.redhat.com/security/vulnerabilities/RHSB-2026-016
7. Ubuntu Security tracker: Ubuntu Security tracker
8. Canonical, “Fixes available in -proposed pocket for CVE-2026-98432” (Nov 2, 2026): ubuntu.com/blog
9. Debian Security tracker: Debian Security tracker · DSA-6568-1
10. SUSE, CVE-2026-98432: SUSE CVE page · SUSE-SU-2026:5091-1 (SLES 15 SP7)
11. Oracle Linux errata: ELSA-2026-500397 · ELSA-2026-500398 · ELSA-2026-500399
12. Amazon Linux advisories: ALAS2023-2026-3251 · ALAS2023-2026-3335 · ALAS2023-2026-3365 · ALAS2-2026-4065
13. AWS Security Bulletin 2026-160-AWS: aws.amazon.com/security/security-bulletins/2026-160-aws
14. AlmaLinux, “CVE-2026-98432: Patched kernels released” (updated Nov 2, 2026): almalinux.org/blog
15. CIQ, “Mitigating CVE-2026-98432 on Rocky Linux 8, 9, 10, and LTS Variants”: kb.ciq.com

Research and ecosystem guidance

16. Anthropic, “Discovering and exploiting vulnerabilities in critical, real-world software with Claude” (Oct 27, 2026): anthropic.com/research
17. Go Security Team, “Protecting against CVE-2026-98432” (golang-announce, Oct 29, 2026): golang-announce · oss-security mirror · go.dev/issue/82717
18. Go 1.24 release notes (MPTCP default): go.dev/doc/go1.24
19. Innora research repository: github.com/sgInnora/innora-cve-research

Press coverage

20. BleepingComputer, “Critical Linux kernel flaw allows remote root attacks on MPTCP servers” (Lawrence Abrams, Oct 30, 2026): bleepingcomputer.com
21. The Hacker News, “Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions” (Oct 2026): thehackernews.com