Skip to content

+Threat Wire · Needs attention

Linux IPv4 TCP use-after-free

A race condition in Linux's IPv4 TCP connection handling can expose kernel memory, crash a host, or allow remote code execution before application authentication.

Prioritize patchingCVE-2026-98432Checked Nov 2

What it means for your AI agents

The machines that run your agents, tool runners, sandboxes and MCP servers are hosts like any other. A host-level flaw reaches everything on the machine, including the provider keys and tool credentials your agents use.

  • Include agent hosts, container nodes and code sandboxes in your patch inventory, not only your web servers.
  • Containers share the host's kernel: rebuilding an agent's image does not fix a kernel flaw.
  • If an affected host was reachable, rotate the model-provider and tool keys stored on it.

Updates

  • Nov 1, 2026 : Atlas updated its distribution review to report fixed RHEL kernels and remaining vendor-specific patch gaps.
  • Oct 30, 2026 : Red Hat published a Critical-impact bulletin and interim network-filtering guidance.
  • Oct 29, 2026 : The Go Security Team published MPTCP applicability guidance, subsequently mirrored on oss-security.
  • Oct 27, 2026 : Anthropic disclosed a working research exploit for remote root command execution against MPTCP listeners.
  • Oct 15, 2026 : The Linux kernel CNA published the CVE record with upstream fix references.

Details

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake. One operation can free stored IPv4 options while another CPU is still reading them to construct a connection reply. The flaw dates to Linux 4.4. The Linux kernel CNA rates it Critical, with a CVSS 3.1 score of 9.8.

The vulnerable processing happens before an application authenticates a connection. A remote peer can trigger a race that discloses kernel memory, corrupts memory, or crashes the host. Anthropic demonstrated root command execution on servers exposing a Multipath TCP (MPTCP) listener.

The Go Security Team warns that the underlying bug is not specific to MPTCP and that similar attacks may be possible without MPTCP listeners. Its guidance notes that Go programs enable MPTCP listeners by default on Linux from Go 1.24, subject to configuration. Disabling MPTCP is not a substitute for patching the kernel.

The upstream fix defers freeing the options until concurrent readers have finished. Distribution vendors backport the fix under their own package versions. Updating an application or rebuilding a container image alone does not patch the host kernel, and installing a new kernel does not by itself prove that the running kernel is fixed.

Risk

Researchers demonstrated root command execution against MPTCP listeners; other IPv4 TCP services may also be affected. Reports reviewed on November 2 did not confirm real-world attacks.

Affected deployments

Linux hosts with an affected kernel and IPv4 TCP networking, including container hosts and Kubernetes nodes. Prioritize reachable MPTCP listeners; other IPv4 TCP services may also be affected.

Evidence and sources6 links

CVE record

The Linux kernel CNA documents the race condition, upstream affected and fixed branches, and Critical CVSS 3.1 severity of 9.8. Distribution package versions must be checked against vendor advisories.

CVE-2026-98432

Vendor advisory

Red Hat describes unauthenticated remote code execution potential and broad IPv4 TCP exposure. Its interim filtering guidance reduces exposure but does not replace kernel updates.

Red Hat RHSB-2026-016

Runtime applicability

The Go Security Team explains MPTCP listener defaults and warns that systems without MPTCP listeners may still be vulnerable to similar attacks.

Go Security Team advisory

Exploit evidence

Anthropic demonstrates root command execution on Linux servers with MPTCP listeners.

Anthropic research disclosure

CISA KEV

CVE-2026-98432 was not present in the CISA KEV feed retrieved on 2 November 2026 (catalog version 2026.10.30). Absence from KEV is not evidence that exploitation cannot occur.

CISA KEV catalog

Technical analysis and distribution tracking

Atlas provides a technical explanation and links to distribution patch trackers. Its 1 November update reports RHEL fixes and outstanding updates elsewhere; consult each vendor for current availability.

Atlas Linux IPv4 TCP analysis

Check your exposure with an agent

Paste this into an AI agent that can see your infrastructure. It asks for a read-only check of what's affected, including the systems behind your agents, and a table you can act on. Copying it changes nothing.

Prompt
Assess whether the infrastructure you can access is affected by Linux IPv4 TCP use-after-free (CVE-2026-98432). Work read-only within your authorized access: do not run exploits, change configuration, restart services or install anything.

1. Confirm the affected and fixed versions from the vendor advisories and CVE records:
   - https://www.cve.org/CVERecord?id=CVE-2026-98432
   - https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
   - https://www.openwall.com/lists/oss-security/2026/10/30/1
   - https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
   - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
   - https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf
   Cite each source and the date you read it. Say plainly what you could not verify.

2. Inventory the systems that could run the affected software, including the hosts, containers, MCP servers, tool runners and sandboxes behind any AI agents. For each, record the asset, environment, owner if known and the version actually running, from read-only evidence (package metadata, version commands, platform inventory).

3. Note which affected systems are reachable from the internet or from agents and tools, and which credentials (model-provider keys, tool tokens, service accounts) are stored on them.

4. Report one row per asset: asset, running version, affected (yes / no / unknown), reachable from, credentials at risk, evidence, and the next step. List anything you could not access as a gap rather than assuming it is safe.

More from the Threat Wire

Briefing source: Cloudflare Radar Zero Wire (Cloudforce One), last checked November 2, 2026. Refreshed here every 30 minutes.