Information current as of 2 November 2026. CVE-2026-98432 is a vulnerability in the Linux kernel's TCP connection handling. It may allow a remote attack without an account on the server or any user interaction. Red Hat currently rates it Critical, with a CVSS 3.1 score of 9.8/10. Administrators should urgently review their kernels and check whether fixes are available for each system. Red Hat CVE record.

The Hacker News covered the issue. Below is our own overview for teams operating servers, applications and Kubernetes clusters, incorporating subsequent vendor advisories.

What happens inside the Linux kernel

The bug involves different CPU cores handling a TCP connection concurrently. When creating a new socket, the kernel transfers an IPv4 options structure to it. Another core may still be using that structure to respond to a retransmitted connection request. If the memory is freed first, this creates a use-after-free: a reference to memory that no longer belongs to the object.

The fix defers freeing the memory until other readers using the RCU mechanism have finished accessing it. The description also covers a related socket migration issue. The first mechanism does not affect IPv6, which copies the options; however, the description identifies a separate IPv6 migration case requiring a separate fix. This should not be interpreted as a blanket assurance that every IPv6 configuration is safe. Technical description in Debian's security tracker.

Remote code execution: what was actually demonstrated

Anthropic reported a demonstration against a Linux server exposing a Multipath TCP, or MPTCP, listening socket. According to the company, the exploit achieved command execution as root without authentication. It first used an information leak to bypass kernel address space layout randomization, then hijacked control flow.

In the reported test, the first stage took 48 minutes and the second took another five. This is the result of a particular experiment, not a prediction of how long it would take to compromise an arbitrary server. The publication does not provide the complete test kernel configuration or exploit code. A research demonstration is also not, by itself, evidence that the vulnerability has been used in attacks against businesses. Anthropic report, Linux section.

MPTCP and Go: it may be enabled without explicit configuration

The Go Security Team notes that, as of Go 1.24, programs enable MPTCP by default for listening sockets on Linux. The review should therefore include services written in Go, even if administrators have not explicitly deployed MPTCP.

The team describes setting GODEBUG=multipathtcp=0 in the process environment as an option. This changes the application's default behavior and needs to be deployed along with an application restart. An explicit SetMultipathTCP call in the code can override this setting.

Disabling MPTCP does not confirm that the vulnerability has been fixed. The underlying bug is not specific to MPTCP, and leaving a single accessible listener can preserve an attack path. The Go Security Team recommends updating the kernel and describes disabling MPTCP separately in each application as a fragile mitigation. Go Security Team announcement.

Patch availability: check the specific package

Distribution status changes independently of a fix being published upstream in Linux. The information below comes from advisories available when this article was prepared; check the linked source again before deployment.

  • Ubuntu: the CVE record, updated on 30 October, marks the base linux package for 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 as vulnerable, with a fix in progress. A planned package version listed there does not mean it has already been released. HWE, cloud and other variants have separate entries. Ubuntu status.
  • Red Hat: the 30 October bulletin lists RHEL 8, 9, 10 and OpenShift, and states that fixes are being expedited. It also provides a procedure for reducing exposure. Bulletin RHSB-2026-016.
  • Debian: the tracker lists fixed linux source packages at 6.1.190-1 for bookworm and 6.12.113-1 for trixie, plus linux-6.12 at 6.12.113-1~deb12u1 for bookworm. Debian tracker.
  • Amazon Linux 2023: fixes for the kernel6.18 and kernel6.12 branches are documented in ALAS2023-2026-3251 and ALAS2023-2026-3335, respectively. Check the advisory matching the branch used by your host.

Earlier reports cited a lower Red Hat rating. The vendor's current record now shows 9.8. The kernel's major version alone does not determine whether it is secure: distributions backport fixes to older branches. Compare the full package version against the vendor advisory. Red Hat rating and explanation of backports.

Procedure for administrators

1. Inventory hosts and running kernels

Start with servers accepting connections from the internet. Then include internal machines, cluster nodes, test environments and machine images used for autoscaling. Record the owner of each service and its available maintenance window.

Collect basic information on the host:

cat /etc/os-release
uname -r
ss -lnt

uname -r shows the running kernel. The output from ss helps inventory TCP ports, but does not by itself establish internet exposure, test for the vulnerability or provide a complete MPTCP inventory. Combine the results with firewall, load balancer and cloud access rule configurations.

2. Select the update for your distribution

Identify the kernel package name, full version and variant, such as standard, HWE or cloud. Check that the relevant advisory confirms a fix for CVE-2026-98432. Install the fix from a supported vendor repository using the procedure for your environment.

Before restarting, verify your backup, console access and ability to boot the previous kernel if something fails. Rolling back to a vulnerable version requires renewed exposure controls and a further remediation plan.

3. Confirm the patched kernel is running

After the scheduled restart, check uname -r again and match the result to the fixed package. Downloading an update alone does not change the kernel already running. If you use live patching, require vendor confirmation that the specific active patch covers this CVE.

Check service availability, user logins, database connections and monitoring. Record the version, deployment time and verification result for each host.

4. Include nodes in Kubernetes

Standard Linux containers share the host's kernel. Updating an application image does not update the node's kernel. Plan node rotation or updates, accounting for available replicas, cluster capacity and PodDisruptionBudget. Update the base machine image too, so autoscaling does not bring back the vulnerable version.

What to do when a patch is not yet available

Red Hat has published a procedure for filtering incoming IPv4 TCP packets containing IP options. The vendor states that this reduces exposure but does not provide complete protection or replace an update. IP options are different from TCP options. Review the rules in the context of your own network and test them before deployment. Red Hat procedure.

Operationally, restrict unnecessary access to services, assign responsibility for tracking advisories and set a date for reassessment. Do not close the security ticket after applying a workaround alone. Closure should require confirmation that the fix is active on the running system.

How Opselis can help

Through our IT administration services, we help inventory servers, plan updates and check services after restarts. Through security and hardening, we review exposure and remediation priorities. If you need support with this vulnerability, contact us with your distributions, host count and availability requirements.