The CTEM framework helps teams find affected servers, prioritize exposure and track fixes when patches arrive weeks apart. CVE-2026-98432 shows why: this Linux bug scores 9.8, and Anthropic demonstrated an AI-written root exploit against multipath TCP listeners. Debian patched a day after disclosure; Ubuntu still had no fix on November 3.
What is CVE-2026-98432?
CVE-2026-98432 is a memory-handling bug in the Linux kernel, the core of the operating system. It affects the code that sets up IPv4 TCP network connections. The kernel releases memory for reuse while another part of it still needs to read that memory. Engineers call this a use-after-free bug.
Think of the first network packet as a request to connect. It can carry extra settings called IPv4 options, which Linux saves for its reply. If the client repeats that request at the right moment, two processor cores work on the same connection: one builds the reply while the other finishes and closes the connection, releasing the saved settings.
The reply now uses memory that has been released. Linux can then read attacker-controlled data. This is a race: timing determines the result.
Per the CVE record, that can leak kernel memory to the attacker and allow writes into kernel memory, all during the handshake, before any login.
The bug arrived in Linux 4.4, released in January 2016. Eric Dumazet wrote a two-line fix that frees the memory only once nothing is still reading it. The CVE was published on October 15 without a score, and the kernel's own CVE team added 9.8 Critical on October 24.
What did Anthropic's AI model do with the Linux bug?
Anthropic's Frontier Red Team wrote on October 27 that "an unreleased, internal research model" found remotely triggerable bugs in the Linux networking stack. An Anthropic researcher is credited as the reporter on the kernel fix.
The model wrote an exploit for servers accepting multipath TCP (MPTCP) connections. MPTCP lets one connection use several network paths at once. Since Go 1.24, Go programs enable it by default for Linux listeners.
In Anthropic's test, a failed attempt at the race dropped the connection handshake without crashing the server, so the attacker could keep trying. Leaking a kernel memory address took 48 minutes. Five minutes later, the exploit ran an attacker-chosen command as root, with administrator privileges: about 53 minutes in total.
Anthropic did not publish the exploit, the kernel version or a success rate, and we found no independent public reproduction. The post also names Anthropic's Cyber Verification Program, which approved Imperum in August.
When did Linux distributions release patches?
Debian fixed Debian 13 on October 16, and Oracle shipped fixed UEK kernels the same day. Amazon Linux had shipped fixes for the affected kernels listed in its advisory by October 30.
Red Hat first logged the bug on October 15 as moderate, a denial-of-service issue that could crash a system. It raised the rating on October 29 and 30 and released fixed kernels for RHEL 8, 9 and 10 on Sunday, November 1. SUSE has fixed many products, with others still pending.
Ubuntu rates the bug Critical. As of November 3, every supported Ubuntu release still read "Vulnerable," with fixed kernels for four releases marked as work in progress. That is 19 days since the CVE with no Ubuntu kernel to install.
The severity scores also differ: 9.8 from the kernel's CVE team, Red Hat and Ubuntu; 8.1 from SUSE, Oracle and Amazon. Oracle calls its score preliminary. Priority can depend on which source your tools use.
How do you apply the CTEM framework in Imperum?
The CTEM framework organizes exposure management into five repeating stages: scoping, discovery, prioritization, validation and mobilization. Our explainer What is CTEM? covers each stage. Follow this CVE through Defensum, the Imperum module for continuous threat exposure management. Illustrative example: the screens below use synthetic data.
Step 1: Scope and discover the affected Linux servers
Scope the cycle to every Linux server that accepts IPv4 TCP connections, internet-facing ones first. In Defensum, mark the assets most important to the business as crown jewels and group assets into business services. Defensum collects inventory and vulnerability findings from supported, configured tools, such as scanners, into a shared record for each asset.
In Detection Lake, the Vulnerabilities page merges advisories from enabled sources into one record per CVE, with severity, known exploitation and exploitation likelihood. This ranks published intelligence; confirming which servers are affected still needs asset and scanner data.
Note which servers run MPTCP listeners, where the demonstrated exploit worked. Red Hat suggests ss -Mlnp but warns that an empty result does not mean a server is safe.
Step 2: Prioritize and validate the exposure
Defensum gives each asset a risk score with an explanation of the signals behind it, such as severity, internet exposure and business criticality. An internet-facing asset with a critical vulnerability can receive a higher priority than its weighted score alone would give it. A score is not a prediction that a breach will occur.
Attack path analysis connects exposed entry points to crown-jewel assets through derived relationships. A possible path describes exposure; it does not establish that an attacker traversed it.
Validate exposure by comparing each server's running kernel with the vendor's fixed version. Where patches are unavailable, check for the temporary filter in step 3.
Step 3: Assign owners and track the work through to a fix
Findings that cross a risk threshold can create or update a Casebook case with their risk context. Group the findings into a campaign with owners and service-level agreement (SLA) targets. Where the vendor has a fixed kernel, install it and check the running version.
Where no patch is available, as with Ubuntu on November 3, the Red Hat and Ubuntu advisories describe a temporary nftables firewall rule. Its expression, ip protocol tcp ip hdrlength > 5 counter drop, drops inbound IPv4 TCP packets carrying IP options. Use the full rule in the advisories; Red Hat warns it "may disrupt necessary workloads."
Record any accepted risk explicitly, including the temporary rule, and close the exception after checking that the fixed kernel is running. Remediation actions follow permissions, connector availability and risk-based approval rules.
What should your team check this week?
- List the Linux servers that accept IPv4 TCP connections, internet-facing first, and note which run MPTCP listeners, such as Go 1.24 or later services.
- Compare each kernel with your vendor's fixed version. Debian, Oracle, Amazon Linux, Red Hat and AlmaLinux have shipped fixes; Ubuntu had not on November 3.
- Where no fix exists yet, test the vendors' nftables rule before rolling it out. Containers with their own networking need it applied separately.
- Recheck the Ubuntu page and the CISA Known Exploited Vulnerabilities catalog until every server runs a fixed kernel.
Questions about CVE-2026-98432?
What is the CTEM framework?
The CTEM framework is a way to run exposure work as a repeating cycle of five stages: scoping, discovery, prioritization, validation and mobilization. Each cycle decides what matters, finds the exposures, ranks them by real risk, checks the top ones and gets the fixes done. In Imperum, Defensum supports that work across assets, identities and exposures.
Are Linux servers without MPTCP safe from CVE-2026-98432?
No. The bug sits in plain IPv4 TCP handling, and Red Hat says any system with a vulnerable kernel and IPv4 TCP networking enabled is affected. Anthropic's root exploit targeted servers with an MPTCP listener, but Red Hat Enterprise Linux, which ships with MPTCP disabled, is still vulnerable. Patch every affected kernel, whatever your MPTCP setting.
Is CVE-2026-98432 being exploited in the wild?
The sources reviewed report no confirmed exploitation in the wild as of November 3. The bug was not in the CISA catalog of known exploited vulnerabilities, and none of the vendors we checked reports exploitation. Anthropic did not publish its exploit code, and we found no independent public reproduction. This can change quickly, so recheck the catalog and your vendor's page.
Does the nftables rule replace the kernel patch?
No. Red Hat and Ubuntu publish the rule as a stopgap. It drops inbound IPv4 TCP packets that carry IP options, which reduces exposure of the vulnerable code path. Red Hat says it is not a substitute for patching, and Ubuntu says it lowers the risk without fully blocking exploitation. Install the fixed kernel as soon as your vendor ships one.
