CVE-2026-98432: Critical Linux Kernel Vulnerability Allows Remote Root Access — Affected Servers and Fixes

CVE-2026-98432 is a serious Linux kernel vulnerability that can allow a remote attacker to trigger memory corruption in the IPv4 TCP networking subsystem. Security researchers have also demonstrated an unauthenticated, zero-click remote code execution (RCE) attack that runs commands as root against a Linux server with a Multipath TCP (MPTCP) listener.

This does not mean that every Linux server can be remotely taken over. The demonstrated exploit requires specific conditions, while the underlying kernel bug may also affect other configurations. For Linux administrators, cloud engineers, and DevSecOps teams, the immediate priorities are identifying vulnerable kernels, checking vendor advisories, and applying security fixes where available.

Last verified: October 30, 2026. Patch availability can change quickly.

CVE-2026-98432 at a glance

Field	Details
CVE ID	CVE-2026-98432
Product	Linux kernel
Component	IPv4 TCP networking stack
Vulnerability class	Race condition / use-after-free (UAF)
Attack vector	Network
Authentication required for demonstrated exploit	No
User interaction required	No
Potential impact	Denial of service, memory corruption, and demonstrated remote root code execution under specific conditions
CVSS v3.1	9.8 (Critical), as listed by Canonical; vendor assessments differ
CVE disclosure date	October 15, 2026
Remote exploit research published	October 27, 2026
Primary remediation	Run a vendor-patched Linux kernel

What is CVE-2026-98432?

CVE-2026-98432 is a use-after-free vulnerability in the Linux kernel's IPv4 TCP connection handling. A race condition can occur when multiple CPUs process related TCP connection events, such as a retransmitted SYN packet and the destruction of a child socket.

Under the affected code path, socket-option memory can be released while another CPU is still reading it. Accessing that released memory can cause a system crash or memory corruption. Depending on the system configuration and exploitation technique, the impact may be more severe.

The core issue is in kernel networking code, rather than in an application such as Nginx, Apache, or an SSH daemon. That matters because a network-triggered kernel flaw may be encountered before an application has a chance to authenticate a user or reject a request.

How does the Linux TCP use-after-free vulnerability work?

The vulnerable sequence involves the kernel handling a TCP connection request and retaining IPv4 socket options from an incoming packet.

1. The kernel processes a TCP connection request and creates the related socket state.
2. Another CPU can concurrently handle a retransmitted request associated with that state.
3. An affected socket may be destroyed, freeing IPv4 options while the second CPU is still using them.
4. The second CPU attempts to read memory that is no longer valid, creating a use-after-free condition.

Relevant kernel functions discussed in the advisory include tcp_v4_syn_recv_sock(), tcp_v4_send_synack(), and ip_options_build().

The upstream fix delays the release of the affected socket-option memory until after an RCU (Read-Copy-Update) grace period, so concurrent readers have completed their work.

Why is this type of vulnerability dangerous?

A use-after-free is not always equivalent to remote code execution. Sometimes it produces only a crash. But if an attacker can influence how released memory is reused, a memory-safety flaw may become a route to information disclosure, control-flow manipulation, or privilege escalation.

For CVE-2026-98432, the remote-root risk is supported by a publicly described research proof of concept, not just a theoretical severity score.

Can CVE-2026-98432 really give attackers remote root access?

Yes, under demonstrated laboratory conditions. In research published on October 27, 2026, Anthropic described an exploit targeting a Linux server exposing an MPTCP listener. The proof of concept required neither credentials nor user interaction and ultimately executed an attacker-selected command with root privileges.

The researchers described two major exploitation stages:

1. Kernel information disclosure: The memory flaw was used to reveal information that helped defeat Kernel Address Space Layout Randomization (KASLR).
2. Code execution: The exploit used the flaw again to interfere with kernel execution and cause a chosen shell command to run as root.

Anthropic reported that its proof of concept took approximately 48 minutes to leak a kernel pointer and five more minutes to achieve command execution. Those figures describe the research environment and should not be treated as universal attack timings.

Critical distinction: The researchers demonstrated remote root execution against a target with an MPTCP listener. They did not establish that all unpatched Linux hosts are susceptible to the same reliable remote-root attack.

Which Linux systems are affected?

The bug dates back to code introduced in the Linux 4.4 development history. However, a distribution's apparent kernel version is not enough to determine whether it is vulnerable: vendors routinely backport security fixes without changing the kernel's major or minor version.

Linux distribution patch status (October 30, 2026)

Distribution or kernel family	Reported status
Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS, 26.10	Listed as vulnerable; fixes in progress on Canonical's tracker
Red Hat Enterprise Linux 8, 9, 10	Affected; Red Hat reports a deferred fix for applicable packages
Debian 12 (Bookworm)	Fixed kernel packages reported, including 6.1.190-1
Debian 13 (Trixie)	Fixed kernel packages reported, including 6.12.113-1
Amazon Linux 2023	Fixed updates exist for some kernel streams; check the exact package
Oracle Linux (UEK)	Relevant security errata available for several releases
SUSE and openSUSE	Varies by product and kernel package; review the vendor advisory

This is a time-sensitive snapshot, not an exhaustive compatibility list. Cloud-specific kernels, extended-support releases, and managed Kubernetes nodes may have different patch timelines.

Upstream Linux kernel versions containing the fix

Upstream branch	First fixed release
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3 development branch	Fix included by 7.3-rc7

Do not compare distribution kernel strings directly to this table. A vendor backport may fix a seemingly older package, while a different build may still require an update.

How to check your Linux server for CVE-2026-98432

The following read-only checks can help you establish what needs investigation.

1. Check the running kernel

uname -r

Record the exact version and build identifier. Compare it with your distribution's CVE advisory, rather than relying only on upstream version numbers.

2. Identify the Linux distribution

cat /etc/os-release

Check whether your distribution has already released a patched kernel package or is still working on one.

3. Review exposed listeners

ss -lntp

Identify internet-facing TCP services, particularly those that may use MPTCP. This command alone does not reliably prove whether a listener uses MPTCP; review the application and socket configuration as well.

4. Inspect TCP request migration configuration

sysctl net.ipv4.tcp_migrate_req

This setting is relevant to one of the affected request-socket paths. A value of 0 does not prove that a server is safe, and changing the setting is not a complete fix.

5. Confirm that a patched kernel is actually running

After installing a vendor-provided kernel update and performing the required reboot, rerun:

uname -r

Then verify that this specific package build is marked fixed by your vendor.

Why MPTCP and Go servers deserve special attention

Multipath TCP (MPTCP) allows a TCP connection to use multiple network paths. The published remote-root exploit used a target running an MPTCP listener, making exposed MPTCP services particularly relevant to immediate risk assessments.

The Go Security Team also warned that, starting with Go 1.24, MPTCP is enabled by default for supported Linux listening sockets. This may surprise operators who did not explicitly opt into MPTCP.

A Go application can temporarily disable MPTCP by default with:

GODEBUG=multipathtcp=0 ./your-server

Applications may explicitly override this behavior. Furthermore, disabling MPTCP does not fix the underlying kernel bug. The Go Security Team strongly recommends upgrading to a patched kernel.

How to fix CVE-2026-98432

The recommended remediation is straightforward in principle: install and boot into a Linux kernel containing the official fix.

Step 1: Read the vendor's security advisory

Start with the advisory for your operating system and kernel package. Confirm whether a corrected package is actually published. A fix marked in progress, pending, or deferred is not yet an installed remedy.

Step 2: Install the released security update

On Debian or Ubuntu, the normal update workflow is:

sudo apt update
sudo apt upgrade

On RHEL-family distributions, the common equivalent is:

sudo dnf upgrade

These commands install available updates; they cannot fix CVE-2026-98432 if your vendor has not yet shipped the relevant patch.

Step 3: Reboot where required

A downloaded kernel package does not protect a host that is still running the previous kernel. Follow vendor instructions for rebooting or activating the fix, then verify the active kernel.

Step 4: Reduce exposure while patches are pending

• Limit unnecessary public TCP listeners.
• Use firewalls and network segmentation to restrict access to sensitive systems.
• Review exposed MPTCP services and disable MPTCP where it is not needed, if operationally safe.
• Monitor kernel errors, unexpected reboots, and unusual network activity.
• Prioritize production servers, cloud infrastructure, and high-value workloads.

These are risk-reduction measures, not substitutes for a kernel patch.

Are Docker and Kubernetes environments affected?

Potentially. Standard containers share the host Linux kernel. Updating a Docker image or application dependency does not repair a vulnerable kernel on the container host.

Review the kernel security status of:

• Docker and container hosts.
• Kubernetes worker nodes.
• Managed node groups and cloud VM images.
• Hosts running internet-facing services or privileged workloads.

Apply the fix at the host or node operating-system level, using the relevant cloud provider or Linux distribution guidance.

Is CVE-2026-98432 being exploited in the wild?

The publicly described exploit is a research demonstration. As of this article's verification date, the primary sources reviewed did not establish a confirmed widespread malicious exploitation campaign.

That distinction matters: proof-of-concept exploitation and confirmed real-world attacks are not the same thing. Administrators should still act promptly because the ability to execute commands as root has been demonstrated in a relevant environment.

Frequently asked questions

Is CVE-2026-98432 critical?

Canonical lists a 9.8 CVSS v3.1 Critical score, while other vendors assess the issue differently. The relevant severity for a specific product should be checked against that vendor's advisory.

Can this Linux vulnerability be exploited without a password?

Anthropic demonstrated an unauthenticated remote-root exploit against a Linux server with an MPTCP listener. The same result has not been established for every Linux server configuration.

Which Linux kernel versions fix CVE-2026-98432?

Upstream fixes include 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, and 7.2.10, with the fix also included in the 7.3 development line. Distribution-specific versions may differ due to backports.

Are Ubuntu servers vulnerable?

Canonical listed multiple Ubuntu kernel packages as affected on October 30, 2026, with fixes still in progress for several supported releases. Check Ubuntu's live tracker for the current package status.

Will disabling MPTCP eliminate the risk?

No. It can reduce exposure to the demonstrated MPTCP-based exploit, but it does not eliminate the underlying TCP use-after-free vulnerability or rule out other attack paths.

Does updating a container image solve the problem?

No. Standard Linux containers share the host kernel, so the host or Kubernetes node needs the patched kernel.

Final thoughts

CVE-2026-98432 demonstrates how a kernel-level networking flaw can become a serious remote-access threat. Researchers have shown that an unauthenticated attacker can achieve root command execution against a suitably configured Linux target, while vendor advisories confirm the broader risk of memory corruption and denial of service.

For security teams, the best response is evidence-driven: inventory affected hosts, verify vendor patch availability, update the running kernel, and reduce network exposure while waiting for fixes. Avoid assuming that every vulnerable host is remotely exploitable—or that a server without MPTCP is necessarily immune.

Sources and further reading

1. Official CVE record: CVE-2026-98432
2. Anthropic: Discovering and exploiting vulnerabilities with Claude (October 27, 2026)
3. Ubuntu CVE-2026-98432 security tracker
4. Red Hat CVE-2026-98432 advisory
5. Debian security tracker: CVE-2026-98432
6. Oracle Linux CVE-2026-98432
7. Go Security Team: Protecting against CVE-2026-98432 when using Go programs

Information checked on October 30, 2026. Always confirm current mitigation and patch status with your Linux vendor before making production changes.