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.
Recommended action
Install your distribution's fixed kernel and verify it is running after a reboot or vendor-supported activation. Updating containers alone does not patch the host.
- 1Inventory running Linux kernels and reachable IPv4 TCP services, including container hosts, Kubernetes nodes, appliances, and managed infrastructure.
- 2Check the running kernel against your distribution or platform advisory, including any backported fixes. Red Hat kernel advisory
- 1Install the fixed kernel, prioritizing Internet-facing hosts and MPTCP listeners. Reboot or use the vendor-supported activation procedure, then verify that the running kernel includes the fix.
- 2Where a patch cannot yet be applied, consult vendor mitigation guidance. Red Hat describes IPv4-option filtering as exposure reduction, not complete prevention; verify compatibility with your network and workloads.
Use this prompt with an agent that can inspect your infrastructure.
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.
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.
Runtime applicability
The Go Security Team explains MPTCP listener defaults and warns that systems without MPTCP listeners may still be vulnerable to similar attacks.
Exploit evidence
Anthropic demonstrates root command execution on Linux servers with MPTCP listeners.
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.
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.
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.
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.