CVE-2026-98432: The Linux Kernel TCP Bug Your Host Must Patch

CVE-2026-98432, a race condition in the Linux kernel's IPv4 TCP connection setup, is rated 9.8 by the kernel's CVE team, and Ubuntu and Red Hat had no fixed kernel as of October 30. For website hosting, the fix depends on whoever controls the server's kernel. A WordPress or Joomla update does not touch it.

Does CVE-2026-98432 put a normal website at risk?

Yes, if the server under your site runs an unfixed Linux kernel from version 4.4 onward and accepts IPv4 TCP connections. That describes nearly every public web server.

CVE-2026-98432 is a race condition in the kernel code that sets up new IPv4 TCP connections. When an attacker wins the race, the kernel reads memory it has already freed. This bug class is called a use-after-free.

The kernel’s own CVE team scores it 9.8 out of 10 on CVSS. The team added that score to the CVE record on October 24, nine days after publishing the CVE. It says the bug can send nearby kernel memory back to an attacker, corrupt kernel memory or crash the system.

The trigger the team describes is a TCP connection request carrying IPv4 Record Route or Timestamp options, resent until the attacker wins the race. The defective code dates to Linux 4.4. Kernel developers applied the upstream fix on October 5, and the fix credits Anthropic researcher Xinyang Ge with the report.

As of October 29, none of the vendor advisories, the CVE record or Anthropic’s post reported attacks. The flaw was also missing from the copy of CISA’s Known Exploited Vulnerabilities catalog that Luxembourg’s CIRCL last updated on October 28. Treat that as a window to patch, not as evidence that the bug is low risk.

Why a WordPress or Joomla update will not close it

The bug lives in the kernel. The kernel handles the TCP handshake before Nginx, Apache, PHP or WordPress sees a single byte of HTTP. Plugin updates, strong admin passwords, two-factor login and CMS hardening all work at a higher layer. None of them change how the kernel frees IPv4 options.

A site can show all green in wp-admin or the Joomla updater while the server under it runs a vulnerable kernel. Your access logs will not help either. The trigger sits below HTTP, so a clean web log proves nothing about attempts against the kernel.

File scanning has the same limit. Tools such as our Antivirus Website Protection look for malicious code in site files, which matters if an attacker has already planted something. No scanner can patch the kernel underneath.

Anthropic said the flaw “was patched upstream and backported to all maintained stable kernel branches.” That refers to kernel.org. Your server gets the fix only when your distribution ships its own kernel package and the machine boots into it.

Containers do not change this. Every container shares the host’s kernel, so rebuilding a WordPress Docker image fixes nothing. The host and every Kubernetes worker node need the updated kernel.

How does the race work, and what did Anthropic's exploit show?

The race happens when two CPUs touch the same connection data at once. When a TCP handshake completes, the kernel hands the IP options stored with the pending request to the new socket without copying them. Another CPU may still be reading those options to answer a resent connection request. If the socket is destroyed at that moment, that CPU reads freed memory.

IPv6 is not affected, because the kernel copies the options for IPv6 connections. The fix is small: the kernel now waits until other CPUs finish reading the options before it frees them.

On October 27, Anthropic said its AI model, Claude, wrote a working exploit after “initial prompting.” The target was a server with a multipath TCP (MPTCP) listener, and the attacker needed no credentials. MPTCP lets one connection use several network paths at once. On Linux, an application has to request it when it opens a socket.

The exploit has two stages:

1. Leak. The race makes the kernel return extra bytes, and one of those replies exposes a kernel address. That defeats KASLR, the randomization that makes kernel addresses hard to predict.
2. Takeover. The same bug overflows a buffer and overwrites a callback pointer with the address of a payload already placed in kernel memory. When the kernel calls that pointer, the payload runs a shell command of the attacker’s choosing as root.

A lost race fails only that one connection attempt. The system does not crash, so the attacker can keep retrying. In Anthropic’s test, leaking the address took 48 minutes and command execution took 5 more. That is one lab result. Other kernels and networks will produce different times.

The MPTCP link needs a caveat. Neither the CVE record nor the patch mentions MPTCP, so the connection comes only from Anthropic’s write-up. That post omits the exploit code, the kernel version and the configuration tested. It also does not say whether servers without an MPTCP listener can be taken over the same way.

On October 29, the Go Security Team added two points. Go 1.24 programs request MPTCP by default on listening sockets. The underlying bug is also not specific to MPTCP, so systems with no MPTCP listener may be open to similar attacks.

Why is the same bug scored 9.8, 8.1, 7.0 and 5.9?

Two judgments drive the spread. The first is how hard the race is to win, and the second is what an attacker gets from winning it. The kernel team rates attack complexity low because it treats both sides of the race as “attacker-induced,” which gives 9.8. Ubuntu’s page shows the same score. As of October 28, NVD displayed it too and had no score of its own.

Oracle and SUSE give 8.1. Their vector matches the kernel team’s on every metric except attack complexity, which they rate high. Amazon scores it 7.0.

Red Hat publishes two scores. Its CVE page says Moderate, 5.9. The page argues that the race is hard to win and a crash is the most likely result, and it adds that “no confidentiality or integrity impact has been demonstrated.” Red Hat’s advisory file, updated October 29, says Important, 8.1, with high confidentiality and integrity impact. Its bug tracker moved from medium to high the same day.

Our read: Anthropic’s write-up describes the confidentiality impact (a kernel memory leak) and the integrity impact (a root command) that the 5.9 says were not shown. A failed race also does not crash the machine and can be retried. That makes “hard to win” a much weaker argument than it first appears.

Which Linux distributions have a fixed kernel for CVE-2026-98432?

As of October 29, Debian, Oracle Linux, SUSE and Amazon Linux had shipped fixed kernels for at least some releases. Ubuntu and Red Hat had not.

Distribution	Status
Debian trixie, Debian 12 (bookworm)	Fixed packages released
Oracle Linux 7-10 (UEK)	Fixed packages released
SUSE Linux Micro 6.2, openSUSE Leap 16.0	Fixed packages released
SLES 15 SP4-SP6 LTSS, SLES 16.0, SLE Micro 5.3-5.5	Fix in testing
SLES 15 SP7	Affected, fix in progress
Amazon Linux 2023 (kernel 6.18 and kernel 6.12 packages)	Fixed packages released; the kernel 6.12 fix is dated October 29
Amazon Linux 2023 default kernel package, Amazon Linux 2	Fix pending
Ubuntu 16.04 through 26.10, including cloud, FIPS and real-time kernels	No fixed kernel; listed as vulnerable or work in progress
RHEL 8, 9, 10, OpenShift 4	Affected, no fix released
RHEL 7	Not affected

On October 29, Red Hat said its fixes were “currently deferred to a future update.” By October 30 it listed RHEL 8, 9, 10 and OpenShift 4 as Affected instead. Neither Red Hat nor Ubuntu has given a release date.

Red Hat says a remote attacker who can reach an exposed TCP service could trigger the race. It also says no available mitigation meets its standards for being easy to deploy, suitable for most installations and stable. None of the other distributions’ advisories lists a mitigation either.

If you build your own kernel, the fix is in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The kernel’s CVE team recommends moving to the latest stable kernel. It also says the community does not support cherry-picking individual fixes.

Watch the version numbers. Distributions backport fixes without moving to a newer upstream release, so a fixed Debian or Oracle kernel can still report an older base version. The distribution’s advisory and package changelog are the authority here, not the upstream number.

Astra, RED OS and ALT: assume affected until the vendor says otherwise

Astra Linux, RED OS and the distributions from BaseALT (ALT Linux) all run Linux kernels, and the bug has been in mainline code since 4.4. Any kernel built from that code without the backport still contains the bug. Our source material has no status from these vendors, so we cannot say which Astra, RED OS or ALT builds are fixed.

Check each vendor’s security bulletins and FSTEC’s vulnerability database (BDU) for an entry referencing CVE-2026-98432. Certified editions usually receive kernel fixes through the vendor’s own bulletins rather than from kernel.org. Installing one outside the normal cycle may mean re-checking that the certified configuration still holds, so budget time for that.

Some organizations own critical information infrastructure (KII) objects under Federal Law 187-FZ. For significant objects, FSTEC requirements include vulnerability management and the controlled installation of updates. Rate this CVE with FSTEC’s criticality methodology, and test the vendor kernel the way the regulator’s update-testing guidance requires.

Record the decision: the CVE, the affected assets, any interim measures and the date each host booted the fixed kernel. That record is what an inspector will ask for.

Shared hosting or a VPS: who installs the fix, and what to check

On shared or managed hosting

On shared hosting and most managed WordPress plans, you cannot replace the kernel. The host has to install the fixed package and reboot into it. Send your host three questions:

• Which distribution and kernel build runs my site’s server?
• Is a fixed kernel package for CVE-2026-98432 available for it yet?
• When will the servers reboot into the fixed build, and will you confirm afterward?

We covered the same dependency in our piece on what a shared-hosting control-panel flaw can mean for your account. When the fix sits below your account, your exposure follows the host’s patch schedule. Nothing you do in your control panel changes that.

On a VPS, dedicated server or container node

This job falls to you or your admin. Install the distribution’s kernel package when it ships, then reboot. Installing the package does not replace the kernel running in memory, so a server can report the update as installed and stay exposed. If your provider sells live kernel patching, ask whether it covers this CVE before you skip the reboot.

• Run uname -r and compare the full build string against your distribution’s advisory, not against an upstream version number.
• On Debian or Ubuntu, list installed kernels with dpkg -l 'linux-image*' and check whether /var/run/reboot-required exists. On RPM-based systems, use rpm -q kernel or your distribution’s equivalent.
• List MPTCP listeners with ss -M -l -n -p. An empty result speaks only to Anthropic’s test scenario. It does not mean the kernel is patched or that no other attack path exists.
• Find services built with Go 1.24 or later that listen on public ports, since they request MPTCP by default.
• Check every container host and worker node, not just the CMS containers.

Practitioner’s note. In our engagements, the most common finding with kernel CVEs is a missing reboot, not a missing package. The package manager reports “up to date,” while uname -r shows a kernel that booted months ago. On clustered hosting, one node is often still running the old kernel after the rest were rebooted. Verify every node individually rather than trusting the change ticket.

Which hosts to fix first while you wait

Where no fixed kernel exists yet, rank your hosts by exposure:

1. Internet-facing hosts that accept IPv4 TCP. Put first the ones with MPTCP listeners or Go 1.24+ services, since those match the scenario Anthropic demonstrated.
2. Container hosts and Kubernetes nodes, where one kernel serves many workloads.
3. Internal servers reachable from user or contractor networks.

Reducing reachability shrinks the pool of attackers, but it patches nothing. Our breakdown of how attackers find and target exposed servers explains why internet-facing hosts get probed first.

None of the advisories or Anthropic’s post says whether either measure lowers the risk: disabling MPTCP in the kernel, or blocking incoming connection requests that carry IP options. If you try a filter, test it against your own traffic before relying on it.

Go services

For Go programs, the Go Security Team says setting GODEBUG=multipathtcp=0 in the environment turns off MPTCP by default at runtime. Adding godebug multipathtcp=0 to the main module’s go.mod does the same at build time. However, code that calls SetMultipathTCP overrides both settings.

The team calls this a fragile mitigation. A single exposed MPTCP listener still leaves the system vulnerable, and the approach assumes every working exploit needs MPTCP. Like the distributions, the team says the best fix is a patched kernel.

If a fixed package exists for your system, install it and reboot this week. If it does not, schedule the reboot window now so the update goes in the day it ships.

FAQ

Does CVE-2026-98432 affect WordPress or Joomla sites?

It affects the Linux server under them, not the CMS. Any site on a server running Linux 4.4 or later without the fix, and accepting IPv4 TCP connections, is exposed however up to date the CMS is.

Is Ubuntu or Red Hat Enterprise Linux patched for CVE-2026-98432?

Not yet. At the end of October, Ubuntu 16.04 through 26.10 and RHEL 8, 9, 10 and OpenShift 4 had no fixed kernel, and neither vendor had given a date. RHEL 7 is listed as not affected.

What is the CVSS score for CVE-2026-98432?

The kernel CVE team, Ubuntu and NVD show 9.8. Oracle and SUSE score it 8.1, and Amazon scores it 7.0. Red Hat gives 5.9 on its CVE page and 8.1 in its advisory file.

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

No attacks had been reported by any vendor, by the CVE record or by Anthropic at the time of writing. The flaw was also absent from a late-October copy of CISA's Known Exploited Vulnerabilities catalog.

Can a website owner fix a Linux kernel vulnerability?

On shared or managed hosting, no: the host has to install the fixed kernel and reboot. On a VPS or dedicated server, you install your distribution's kernel package, reboot, and then confirm the new build with uname -r.

If my host says the kernel is patched, does the server still need a reboot?

Yes, unless the host uses live patching that covers this CVE. An installed kernel package does not replace the kernel already running in memory.

A kernel patch is your host’s job, but watching the sites on top of it can be ours. A SiteGuarding website protection package adds monitoring and malware cleanup while you wait for a fixed kernel to ship.