CVE-2026-98432 Linux Kernel Vulnerability Response Guide

CVE-2026-98432 is a use-after-free vulnerability in the Linux kernel’s IPv4/TCP processing. It carries a risk of kernel crashes and memory corruption, and Anthropic demonstrated an attack that executed commands with root privileges, without authentication or user interaction, on a server with an exposed MPTCP listener.

The Linux CNA’s CVSS v3.1 rating is 9.8 Critical. Risk ratings and patch status may differ by distribution; this post is a response guide compiled from public advisories.

What to do first, by role

Security officers

Start with Linux assets whose TCP services can be reached from outside. Survey the distribution, running kernel, and installed kernel packages of physical servers, VMs, and container hosts together. Check the basic information with uname -r and cat /etc/os-release, then compare it against your distribution’s CVE notice and package release numbers.

Check first for externally reachable MPTCP listeners, the condition of the published attack demonstration, and include Go-based services in the scope. Do not exclude systems from patching just because they have no MPTCP listener. Do not look at kernel version numbers alone; also check whether your distribution has backported the fix.

CISOs

Set patch priorities based on internet exposure and service impact. Public research has demonstrated root remote code execution in an MPTCP environment. The Linux CNA rates it CVSS v3.1 9.8 and Red Hat rates it 8.1, with a Red Hat product severity of Important. Distinguish between a demonstration in a research environment, per-distribution ratings, and actual exploitation on production networks.

In practice, check public TCP services, business-critical servers, and hosts shared by many services first. Track per-distribution fixed package availability and reboot and service switchover schedules in a single list, and include confirmation that the running kernel has the fix in your completion criteria.

Developers

You need to check the operating system kernel, not application libraries. Apply the fixed kernel package provided by your distribution, and check the actual running kernel after rebooting. Rebuilding only the containers or restarting only the applications cannot substitute for applying the fix to the host kernel.

Changing net.ipv4.tcp_migrate_req=0 does not fix the problem in the default path that handles retransmitted SYNs. Rather than cherry-picking individual commits, the kernel project recommends updating to a stable release that includes the fix.

Small businesses and outsourced operations

Ask your operations vendor for the results of their response, along with the CVE number. You can simply pass on: “Please confirm whether we are affected by CVE-2026-98432, the distribution and kernel package on our servers, whether a fixed version is available, and whether it has been applied and the servers rebooted.”

For managed hosting, check the provider’s notice; for VMs you operate yourself, check the kernel status of the guest operating system. If there is no patch yet, restrict unnecessary external access and keep checking for the fix announcement.

CVE details

While an IPv4 TCP connection is being created, option memory shared by the request socket and the child socket can be freed while still in use on another CPU. The cause is a race condition in building the SYNACK response to a retransmitted SYN or in migrating the request socket. The fix changes the code to free the memory after the RCU grace period.

The current CVSS ratings from the Linux CNA and Red Hat both rate the impact on confidentiality, integrity, and availability as high. The scores differ because the Linux CNA rates attack complexity as Low while Red Hat rates it as High. Red Hat’s score is a provisional rating under review. Check both the public research demonstrating MPTCP remote code execution and the actual exposure of your production environment. See the original ratings ↓

Checked 2026-10-30 15:45 KST · KEV catalog as of 2026-10-29 · EPSS calculated 2026-10-29. Risk indicators change frequently.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Linux kernel use-after-free, made simple

Memory that was already returned gets used again

The problem is that one task returns memory that another task is still using. If the returned space is reused for something else and the old address is still read or written, the wrong data is accessed.

Can I check this from the website address alone?

This vulnerability is a TCP handling problem inside the operating system. It cannot be determined from web response headers or the PHP version, so you need to check the server’s running kernel and the distribution’s patch history.

Am I safe if I use IPv6?

According to the official description, IPv6 is not affected by the first problem, the shared IPv4 options. However, a separate problem is mentioned in IPv6 request socket migration related to the CALIPSO option. Do not conclude that the whole server is safe just because it uses IPv6.

Affected and fixed versions

The following is based on the upstream kernels published by the Linux CNA. The change that caused the bug was introduced in 4.4, and each release line includes the fix starting from the version below.

Do not apply these numbers directly to distribution kernels. For example, Ubuntu’s 6.8.0-… or RHEL packages must be checked against the fixed release numbers in the distribution’s security notice. For lines from 4.4 onward that are not in the table, check impact and support status separately. [Linux CNA]

Per-distribution patch status

This is the advisory status of major products and packages as checked on 2026-10-30. Ubuntu 16.04 and 18.04 also need checking. Canonical marks the linux package for both versions as Vulnerable. A version missing from the table below is not necessarily safe, and even within the same distribution the result differs between the generic, HWE, and cloud kernels.

Ubuntu’s “work in progress” label does not mean a fixed package has already been released. Red Hat is not offering a general mitigation either. When you actually take action, check the latest status again at the links above.

On GCP VMs, also check that the actually installed kernel package is linux-gcp. The versions in the GCP rows cannot be applied as is to the generic linux, HWE, or GKE kernels.

A fix being available is not the same as your server being remediated. You need to confirm that the fix has been applied to the kernel actually installed and running. Ignored, shown for reasons such as end of support, is also different from Not affected, and do not treat Ubuntu HWE and cloud kernels, Oracle UEK and RHCK, or SUSE service packs and packages as interchangeable.

Remediation is complete only when the running kernel is confirmed

1. Check the distribution and running kernel with cat /etc/os-release and uname -r.
2. Check the distribution notice to see whether a fix is available for the kernel package in question, and update.
3. Complete the application procedure suited to your environment, such as a reboot or a live patch that supports this CVE.
4. Confirm the running kernel, the patch status, and normal service operation, and record the results.

Additional response measures

What to check first for MPTCP and Go services

Distinguish the demonstrated attack path from the underlying bug.

MPTCP (Multipath TCP) is a TCP extension that lets a single connection use several network paths. The unauthenticated root code execution case published by Anthropic requires an exposed MPTCP listener. However, the Go security team explains that the underlying bug is not limited to MPTCP and that similar attacks may be possible on systems without an MPTCP listener.

Starting with Go 1.24, listening sockets on Linux use MPTCP by default. Whether it is actually used depends on kernel support, the program’s Go compatibility settings, and per-socket settings. Do not conclude whether something is exposed based only on the Go version or the kernel’s MPTCP setting; check the listeners your services create and how they can be reached.

The Go proposal #82717 to turn off the MPTCP default was, as of our check on 2026-10-30, still under discussion, and the change of default has not been decided. Do not assume MPTCP is disabled in your running programs based on that proposal alone.

Setting GODEBUG=multipathtcp=0 in a program’s environment can be used as a temporary measure to turn off the MPTCP default, but an explicit net.ListenConfig.SetMultipathTCP setting can override it. Do not treat disabling MPTCP alone as completed remediation. The root fix recommended by the Go security team is updating to a fixed kernel.

Anthropic research · Linux RCE demonstration · Full Go security team notice · forwarded to oss-security · Go 1.24 default settings

Sources and references

• Anthropic · Unauthenticated root RCE demonstrated in an MPTCP environment — public research · Linux case
• Go security team · CVE-2026-98432 guidance — full official notice · forwarded to oss-security
• Go · multipathtcp default and compatibility — Go 1.24 · GODEBUG
• Go · proposal to stop using MPTCP by default — proposal #82717 · under discussion · default change not decided
• Linux kernel · MPTCP architecture and sockets — official kernel documentation
• Linux CNA · official CVE-2026-98432 record — CVSS · affected range · backport versions
• Linux kernel · IPv4 RCU release fix — upstream fix commit
• NVD · CVE-2026-98432 — vulnerability database
• Ubuntu · per-release patch status — Vendor Advisory
• Red Hat · impact assessment and response status — Vendor Advisory · CWE-825
• Red Hat · raw severity and per-product patch status — Security Data API · CVSS 8.1 · Important
• Debian · fixed packages in the security repository — Security Tracker · bookworm / trixie
• Amazon Linux · fix status by package — Amazon Linux 2 / 2023 · ALAS
• Oracle Linux · UEK fix errata — Oracle Linux 7 / 8 / 9 / 10
• SUSE / openSUSE · status by product and package — fixed package list · check per service pack
• FIRST · EPSS score explanation — indicator predicting likelihood of exploitation
• FIRST · raw EPSS data for CVE-2026-98432 — calculated 2026-10-29
• CISA · Known Exploited Vulnerabilities catalog — Known Exploited Vulnerabilities