Konfirmity
All security advisories

//security advisory

CVE-2026-98432: Linux Kernel TCP Use-After-Free

CVE-2026-98432 is a flaw in how the Linux kernel sets up incoming IPv4 TCP connections. An attacker who can reach any listening TCP port can trigger it without logging in, before your application sees the connection. Anthropic says its model built a working remote root exploit against servers with a multipath TCP listener. Install your distribution’s fixed kernel and reboot. Ubuntu and Red Hat Enterprise Linux have not shipped one yet, so filter the trigger packets until they do.

On this page
  1. Are you affected?
  2. What to do
  3. Fixed versions
  4. Check your hosts
  5. Until you patch
  6. How the flaw works
  7. Exploitation status
  8. Where the sources differ
  9. Timeline
  10. Recording it for compliance
  11. FAQ
  12. Sources

Are you affected by CVE-2026-98432?

Almost every Linux server that accepts IPv4 TCP connections is in scope. What differs is whether your distribution has shipped a fix. Find the row that describes you.

  • Your servers run Ubuntu or RHEL

    Including Rocky Linux, AlmaLinux, CentOS Stream, OpenShift and RHEL CoreOS nodes

    Act now

    No fixed kernel from Ubuntu or Red Hat yet. Apply the packet filter now and put internet-facing hosts first in line for the fix. Until you patch

  • You run Go 1.24+ services on Linux

    Go opens multipath TCP listeners by default where the kernel allows it

    Act now

    These hosts match the setup Anthropic’s exploit used. Patch them first, and turn off multipath TCP if you do not need it. Multipath TCP

  • Your servers run Debian, Amazon Linux, Oracle UEK or current SUSE

    Fixed kernels are published

    Update needed

    Install the fixed kernel and reboot. The fix is not active until the host boots into it. Fixed versions

  • You run containers or Kubernetes

    Docker, Podman, EKS, GKE, AKS or self-managed nodes

    Update needed

    Containers use the host kernel, so new images do not help. Patch and reboot the nodes, or roll to a fixed node image from your provider.

  • You use managed or serverless platforms only

    Lambda, Cloud Run, Fargate, managed databases and similar services

    Low risk

    The provider runs the kernel. Watch for its notice, and record the dependency in your vendor review.

  • Your hosts run Linux older than 4.4, or RHEL 6 or 7

    Kernels that predate the vulnerable code

    Protected

    Not affected by this flaw, according to the CVE record and Red Hat. These kernels are out of support for other reasons.

What to do

Patch and reboot where a fix exists. Where it does not, cut off the trigger and shrink the proven attack path while you wait.

  1. List your Linux hosts and their kernels

    Include container hosts, Kubernetes nodes, appliances and cloud images, not just application servers. Compare each against your distribution’s status, not the upstream version list. How to check
  2. Install the fixed kernel and reboot

    Debian, Amazon Linux, Oracle UEK and several SUSE releases have one now. A kernel update does nothing until the host boots into it. Fixed versions
  3. Filter IPv4 options where you cannot patch yet

    On Ubuntu and the RHEL family, apply the nftables rule that drops incoming TCP packets carrying IPv4 options. Ordinary traffic does not use them. The rule
  4. Find and remove multipath TCP listeners

    Anthropic’s exploit targeted them, and Go 1.24 and later open them by default. Turn multipath TCP off where you do not use it, and patch hosts that have these listeners first.
  5. Record the decisions

    Note which hosts were exposed, which controls you applied, and when each moved to a fixed kernel. For compliance

Fixed versions

Distribution kernels carry the fix under their own version numbers. Use the upstream list only for self-built or vanilla kernels.

Upstream Linux

First fixed upstream release per branch
BranchFixed in
7.3 (mainline)7.3
7.27.2.10
6.18 (longterm)6.18.56
6.12 (longterm)6.12.113
6.6 (longterm)6.6.159
6.1 (longterm)6.1.190
5.15 (longterm)5.15.223
5.10 (longterm)5.10.272
4.4 to 5.4No upstream fix (end of life). Distribution backports only.

Every kernel from 4.4 onward without the fix is affected, according to the CVE record. The kernel team recommends moving to the latest stable release for your branch rather than cherry-picking the commit.

Distributions, as of 1 November 2026

Distribution kernel status for CVE-2026-98432
DistributionStatusDetail
UbuntuNot fixedFixes in progress for 22.04, 24.04, 26.04 and 26.10 (tracker updated 30 October). 16.04, 18.04 and 20.04 listed as vulnerable. No Ubuntu Security Notice yet.
Red Hat Enterprise LinuxNot fixedRHEL 8, 9 and 10 and OpenShift 4 and 5 affected; RHEL 6 and 7 not affected. Rated Critical. Bulletin RHSB-2026-016 says fixes are being expedited.
AlmaLinuxIn testingkernel-4.18.0-553.180.2.el8_10, kernel-5.14.0-687.61.2.el9_8 and kernel-6.12.0-211.69.2.el10_2 in the testing repository since 30 October, ahead of RHEL.
DebianFixed12 bookworm: linux 6.1.190-1 (DLA-4841-1), linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1). 13 trixie: 6.12.113-1 (DSA-6568-1). Unstable fixed.
SUSEPartly fixedSLES 16.0 fixed in kernel-default 6.12.0-160000.40.1, plus several SLE 15 service packs and SLE Micro images. Other products pending. SUSE scores it 8.1.
Oracle LinuxFixed (UEK)Unbreakable Enterprise Kernel errata for Oracle Linux 7 to 10 on 16 October: ELSA-2026-500397, -500398 and -500399.
Amazon LinuxFixedAmazon Linux 2023 kernel, kernel6.12 and kernel6.18, and Amazon Linux 2 core and 5.4, 5.10 and 5.15 Extras kernels, all fixed by 30 October.

Trackers: Ubuntu · Red Hat · AlmaLinux · Debian · SUSE · Oracle · Amazon Linux

Red Hat says any product built on the RHEL kernel, including RHEL CoreOS, OpenStack Platform and Virtualization, is potentially affected. Oracle’s page lists only its UEK kernels; check the Red Hat compatible kernel separately.

Check your hosts

Run these on the host, not inside a container. A container reports the host’s kernel.

Kernel version and pending reboots

Linux host
uname -r                            # running kernel
dpkg -l 'linux-image*' | grep ^ii   # Debian and Ubuntu: installed kernels
rpm -q kernel                       # RHEL family: installed kernels
needs-restarting -r                 # RHEL family: is a reboot pending?

If the newest installed kernel is fixed but uname -r shows an older one, the host still needs a reboot.

Multipath TCP listeners

Linux host
sysctl net.mptcp.enabled    # 1 means applications may open MPTCP sockets
sudo ss -Mlnp               # MPTCP listeners and the processes that own them

ss -M lists only multipath TCP sockets, so empty output means no such listener. A host has one only if an application asks for it. Go programs built with Go 1.24 or later do so by default for listening sockets, per the Go Security Team; the default follows the go line in the program’s go.mod (GODEBUG docs). AlmaLinux and CIQ say multipath TCP is off by default on their kernels.

On some RHEL 8 era kernels, CIQ found ss did not show the multipath row, so use the sysctl check there.

Until you patch

These controls reduce exposure. None of them fixes the kernel, and each should come off once the host runs a fixed kernel.

1. Drop TCP packets that carry IPv4 options

The bug is only reachable through a connection request that carries IPv4 options, such as Record Route or Timestamp, according to the CNA’s scoring notes. Normal TCP traffic does not use them; TCP’s own options live in the TCP header and are unaffected. This is AlmaLinux’s rule, which hooks prerouting so it also covers traffic the host forwards to containers. It lives in its own table, works alongside firewalld, and is safe to run more than once.

Linux host, as root
sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF
sudo nft list table ip cve_2026_98432        # counter shows drops
Remove after rebooting into a fixed kernel
sudo nft delete table ip cve_2026_98432
  • The rule does not survive a reboot. Reapply it if you reboot before a fixed kernel is available.
  • Traffic between containers on the same host may bypass it, AlmaLinux warns.
  • Do not use it on networks that rely on CIPSO security labels, which travel in IPv4 options.
  • Red Hat’s version hooks input instead, and Red Hat says it “reduces exposure to this vulnerability but cannot fully prevent it.”
  • If your edge firewall or cloud load balancer can drop IPv4 packets with options, doing it there protects every host behind it.

2. Turn off multipath TCP if you do not use it

Linux host
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0
sudo ss -Mlnp      # existing listeners stay MPTCP: restart the services listed

This removes the setup Anthropic’s exploit used, not the bug. CIQ’s testing found a plain TCP listener still processed the trigger with multipath TCP off, so do not rely on this step alone. The setting is per network namespace: containers keep their own value unless you set it there too, for example with Docker’s --sysctl net.mptcp.enabled=0.

For a single Go program, GODEBUG=multipathtcp=0 in its environment, or godebug multipathtcp=0 in go.mod, turns the default off. The Go team calls program-by-program changes “a fragile mitigation” and is discussing its response in golang/go#82717.

3. Reduce what is exposed

Close TCP ports the internet does not need, keep multipath TCP listeners off public networks, and patch internet-facing hosts first. One extra hardening step has been proposed on oss-security: the init_on_free=1 boot parameter zeroes freed memory, which limits what the memory leak can reveal. It needs a reboot, costs some performance, and is not vendor guidance.

How the flaw works

A race between two CPUs over the same piece of memory, during the TCP handshake.

When a connection request arrives with IPv4 options, the kernel saves the options so it can echo them in its reply. Once the handshake completes, it hands that saved copy to the new connection without duplicating it. If the client resends its connection request at the right moment, another CPU can be building a reply from the same options while the new connection is closed and its memory freed. The reply code then reads memory that no longer belongs to it.

The CNA’s scoring notes say this can send leftover kernel memory back to the attacker, let stale lengths and offsets steer kernel writes out of bounds, or crash the host. It all happens before any application or login check runs. A similar race exists when request socket migration is on (net.ipv4.tcp_migrate_req=1, off by default). IPv6 is not affected by the main race because the kernel copies IPv6 options; a narrower IPv6 migration case will be fixed in a separate patch.

The fix, by Eric Dumazet, makes the kernel wait until no CPU can still be reading the options before freeing them, as other code paths already did. It credits Xinyang Ge of Anthropic with the report.

Exploitation status

A working exploit exists in a lab. No attacks have been reported.

  • Anthropic’s exploit. Anthropic says an unreleased Claude model wrote an exploit that lets a remote attacker “run arbitrary commands as root, without any credentials or user interaction” on servers with a multipath TCP listener. It first leaks a kernel address to defeat address randomisation, then overwrites a callback pointer. A lost race “only fails the handshake,” so the attacker can retry. In its test, the leak took 48 minutes and command execution another five. The code is not public.
  • In the wild. No vendor reviewed reports exploitation, and the CVE is not in CISA’s KEV catalog as of 1 November 2026.
  • Public code. About 40 GitHub repositories reference the CVE as of 1 November. Most are checkers and mitigations, but several describe race triggers or proofs of concept. We have not tested them and do not link them.
  • Signs to watch. Failed attempts do not crash the host. Look for inbound SYNs with IPv4 options (the nftables counter above counts them) and for unexplained kernel oopses mentioning ip_options_build or skb_under_panic.

Where the sources differ

Vendors disagree on how hard this is to exploit, and coverage often reduces it to a multipath TCP bug. Here is what each source says and how we read it.

Points where sources disagree
QuestionWhat the sources sayOur reading
How severe is it?The kernel CNA and Red Hat score it 9.8, with low attack complexity. SUSE, Oracle and Amazon score it 8.1 with high attack complexity, because the attacker has to win a race. Red Hat rated it Important until 30 October, then raised it.Treat it as critical. Anthropic showed the race can be won remotely, and a lost race does not crash the host, so the attacker can keep trying.
Does it need multipath TCP?Anthropic’s exploit targeted servers with a multipath TCP listener. The CVE record and the fix do not mention multipath TCP. The Go Security Team and CIQ say plain TCP listeners still reach the bug.Multipath TCP listeners are the proven path and the first to patch. Every IPv4 TCP listener is exposed to the bug.
Code execution or denial of service?Red Hat’s CVE page says the issue primarily results in a crash or possible memory corruption. Its bulletin says it could be used to trigger remote code execution.Plan for remote code execution. Anthropic reports a working root exploit.
Does the packet filter fully protect me?Red Hat says its rule reduces exposure but cannot fully prevent it. AlmaLinux says traffic between containers on the same host may bypass it.A strong stopgap for traffic arriving from the network. It does not replace the kernel fix.

NVD has not published its own analysis; scanners that read NVD alone may show no score yet.

Timeline

Times are UTC.

  1. 2016-01-10

    Linux 4.4 ships the change that lets request sockets be processed without the listener lock, which introduced the race.

    Linux kernel CVE announcement

  2. 2026-10-15 · 12:08 UTC

    The Linux kernel CNA publishes CVE-2026-98432. 7.2.10, 6.18.56, 6.12.113 and 7.3-rc7 already carry the fix; backports to older longterm branches follow.

    linux-cve-announce

  3. 2026-10-16

    Oracle publishes Unbreakable Enterprise Kernel errata for Oracle Linux 7 to 10.

    Oracle Linux CVE page

  4. 2026-10-24

    Amazon Linux 2023 fixes its kernel6.18 package.

    Amazon Linux Security Center

  5. 2026-10-27

    Anthropic describes a remote root exploit for the bug, written by an unreleased Claude model, against servers with a multipath TCP listener.

    Anthropic

  6. 2026-10-29

    The Go Security Team warns that Go 1.24 and later open multipath TCP listeners by default on Linux. SUSE publishes fixed kernels for several products.

    oss-security

  7. 2026-10-30

    Red Hat raises its rating to Critical and publishes bulletin RHSB-2026-016 with an nftables mitigation. AlmaLinux puts fixed kernels in testing. Amazon Linux fixes its remaining kernels.

    Red Hat RHSB-2026-016

  8. 2026-10-31

    The CVE record lists fixes for all eight maintained branches. NVD still shows it as Received, without its own analysis.

    CVE record

Recording it for compliance

A critical, network-reachable kernel flaw with no fix on two major distributions is exactly what auditors ask about. Record the assessment, the interim controls and the patch dates.

Controls to record this event against
FrameworkControlWhat to record
ISO 27001:2022A.8.8Management of technical vulnerabilities. Record when you assessed CVE-2026-98432, which hosts were affected, the risk decision for each, and the date each rebooted into a fixed kernel.
ISO 27001:2022A.8.20, A.8.22Network security and segregation. Record the interim packet filter, where it is applied, and which listeners you removed from public exposure.
ISO 27001:2022A.8.9, A.8.32Configuration and change management. Record the multipath TCP and firewall changes as changes, including when you remove the filter.
ISO 27001:2022A.5.19, A.5.22Supplier security. Track the distribution and cloud provider fixes you depend on, especially Ubuntu and Red Hat.
SOC 2CC7.1Identifying vulnerabilities. Show the CVE was picked up and assessed against your inventory.
SOC 2CC6.6, CC8.1Boundary protection and change management for the interim controls and kernel rollout.
SOC 2CC9.2Vendor risk for managed platforms that run the kernel.

Evidence to keep: the date you assessed it, the host inventory with kernel versions, which hosts had multipath TCP listeners, the filter and sysctl changes with their dates, and each host’s reboot into a fixed kernel. If your patch policy sets a deadline for critical vulnerabilities that Ubuntu or Red Hat cannot meet, record the exception and the compensating controls.

For how these controls work day to day, see our guides to ISO 27001 vulnerability management, SOC 2 vulnerability management and ISO 27001 change management.

CVE-2026-98432 FAQ

Short answers. The sections above have the detail and sources.

What is CVE-2026-98432?

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code. When a connection request carries IPv4 options, the kernel could free those options while another CPU was still reading them to answer a retransmitted SYN. A remote peer needs no login to reach it. The Linux kernel CNA scores it CVSS 3.1 9.8.

Which Linux kernel versions fix CVE-2026-98432?

Upstream, 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Kernels from 4.4 onward without the fix are affected. Distribution kernels carry the fix under their own version numbers, so check your distribution's tracker instead of comparing with the upstream list.

Are Ubuntu and RHEL fixed for CVE-2026-98432?

Not as of 1 November 2026. Ubuntu's tracker lists fixes in progress for 22.04, 24.04, 26.04 and 26.10 and none released. Red Hat lists RHEL 8, 9 and 10 and OpenShift as affected and says it is expediting fixes. AlmaLinux has fixed kernels in its testing repository. Debian, Oracle UEK, Amazon Linux and several SUSE releases are fixed.

Is CVE-2026-98432 being exploited?

No attacks in the wild have been reported, and it is not in CISA's Known Exploited Vulnerabilities catalog as of 1 November 2026. Anthropic says its model wrote a remote root exploit for servers with a multipath TCP listener, which took 53 minutes in its test, but it has not published the code.

Does turning off multipath TCP protect me?

Only partly. It removes the setup Anthropic's exploit used, but the bug is in ordinary IPv4 TCP handling. The Go Security Team says systems without multipath TCP listeners may be vulnerable to similar attacks, and CIQ found the trigger still reaches plain TCP listeners with multipath TCP off. Filter IPv4 options and patch the kernel.

Is there a workaround for CVE-2026-98432?

Red Hat and AlmaLinux publish an nftables rule that drops incoming IPv4 TCP packets carrying IP options, which the trigger needs. Red Hat says it reduces exposure but cannot fully prevent exploitation, and AlmaLinux notes traffic between containers on the same host may bypass it. It is a stopgap until you reboot into a fixed kernel.

Are Go programs more exposed to CVE-2026-98432?

Go programs built with Go 1.24 or later open multipath TCP listeners on Linux by default when the kernel allows it, according to the Go Security Team. That matches the setup Anthropic's exploit needed. Setting GODEBUG=multipathtcp=0 turns the default off, but the Go team calls this fragile and recommends a patched kernel.

Do containers need a new image to fix CVE-2026-98432?

No. Containers use the host's kernel, so rebuilding images changes nothing. Update and reboot the container hosts and Kubernetes nodes. Managed services that run the kernel for you, such as serverless platforms, are the provider's responsibility.

Sources