CVE-2026-98432: What the Linux TCP Bug Means for Kubernetes Nodes

CVE-2026-98432 is a bug in the part of the Linux kernel that sets up TCP connections. The kernel CVE team published it on 15 October 2026 with a CVSS 3.1 score of 9.8. If a Linux machine answers TCP connections directly and runs an unpatched kernel, anyone who can reach one of those ports can crash it, and Anthropic has shown that the bug can also give the attacker root. The attacker needs no account on the machine, and nobody on it has to do anything. On a Kubernetes cluster that machine is a node, and the fix is a new kernel on every node, control plane included. Kubernetes itself never touches the kernel; whoever runs the nodes has to swap it. On Syself Autopilot that is us: release 1.36 v8 has the fixed kernel, the upgrade swaps every node for you, and our assessment for the 1.36 line is on the Version Hub.

Updated 3 November 2026 with the current vendor status and the 1.36 v9 release.

CVE-2026-98432 explained: how the Linux TCP bug works

A TCP connection opens with the usual three packets: the client's SYN, the server's SYN-ACK, and the client's ACK. Between the SYN and the ACK the server's kernel keeps a small record of the half-open connection. If the SYN carried IP options, the record stores those too. IP options are an old, rarely used part of the IP header, for things like asking routers to note the path a packet takes. Almost nothing uses them today, but the kernel still parses and stores them, and the bug is in how that stored copy is handled. The attacker just puts options on the SYN they send; the content does not matter, only that there is something to store.

When the ACK arrives, the kernel creates the real connection from the record. It should copy the IP options over. Instead, both the record and the new connection point at the same block of option bytes, and the record is not deleted the instant the connection exists, so for a short moment both are around. Sharing one block would be fine if a single CPU core handled everything for this connection. It doesn't: on a machine with several cores, two of them can work on the same half-open connection at once, and for performance the kernel handles these records without taking a lock. Nothing stops two cores from touching the record at once.

The attacker uses that window. They send the SYN a second time, which the kernel treats as a retransmission of a lost packet, so a second core picks up the record and starts building another SYN-ACK from the shared option bytes. At the same time the attacker closes the connection they just opened. The first core tears it down and frees the option block while the second core is still reading from it. Freed memory is handed out again to whatever asks next, so the second core is now reading memory that may already belong to something else (a use-after-free), and whether that happens depends on which core gets there first (a race).

Three things can happen. If the timing is off, nothing: the handshake fails and the attacker tries again. If the timing lines up and the freed memory now holds junk, the kernel panics, and the node goes down and takes its pods with it until it reboots. If the memory holds data the attacker arranged to put there, the kernel uses their bytes as if they were its own. Some of those bytes tell the kernel how long the option data is and where to write into it, so with the right bytes in place the attacker gets the kernel to write outside the memory it should. The kernel CVE team's write-up names control-flow corruption as the consequence, the point where the kernel runs code the attacker chose, as root. The SYN-ACK built from the stale bytes also goes back to the attacker, so the same bug leaks neighboring kernel memory to them, which is how they learn where things sit. How an attacker arranges what lands in freed kernel memory is beyond this article; Anthropic reports getting root with an exploit for this bug on a server using multipath TCP (MPTCP), more on that below. A failed attempt costs nothing but one failed handshake, so they can keep trying for as long as the port is reachable.

The fix, kernel commit e3f33b0a1d89, makes the kernel hold on to the old option block until no core can still be reading it. The vendors disagree about how hard the race is to win, which the scoring system calls attack complexity. The kernel CVE team and Red Hat rate the complexity low and score it 9.8. The kernel team's reasoning is that both sides of the race, the retransmitted SYN and the teardown, are caused by the attacker, so the attacker controls the timing. SUSE, Oracle and Amazon rate the complexity high and score it 8.1.

Which systems are at risk, and what a load balancer changes

A Linux machine is at risk if it runs an unpatched kernel from 4.4 onward and its own kernel completes TCP handshakes with packets the attacker sent. Which kernel does the handshake is also what decides whether a load balancer in front of the node changes anything.

There are two kinds. A pass-through balancer forwards the client's packets more or less as they are, perhaps rewriting addresses on the way, and your node's kernel does the handshake with the attacker. A terminating balancer, usually called a proxy, completes the handshake with the client itself and then opens a separate connection to your node. The attacker's packets never get past it.

The Hetzner Cloud Load Balancer is the terminating kind. For traffic that comes through it, the kernel that does the handshake with the attacker is the balancer's, and the connection to your node is a separate one built from packets the balancer generates. That balancer runs on Hetzner's own systems, which only Hetzner operates and maintains, so it sits outside the machines you run; this article is about your nodes. You can check the termination in your own logs: unless you enable the PROXY protocol, a small header the balancer can add to pass on the real client address, the client address your node records is the balancer's, since that is where the TCP connection came from.

Ports the node answers on its own public address do reach its kernel. Every Service of type LoadBalancer also opens a NodePort on every node. The balancer uses it to reach your pods, and so can anyone who sends packets to the node's address directly. The same applies to hostPort and to pods running with hostNetwork. All containers on a node share its kernel, so any port the node answers directly exposes that kernel. Our docs are explicit about treating the NodePort as public.

What the fix takes on Kubernetes nodes you run yourself

On Syself Autopilot the list below is our work, and the next section describes how we did it. If you run the nodes yourself, this is the list, and you go through it once per cluster.

Find out which kernel each node runs. kubectl get nodes -o wide shows it in the KERNEL-VERSION column. For a distribution kernel, check the vendor advisory; for a stable kernel, compare with the fixed versions listed in the FAQ.
Work out which ports the nodes answer directly (see above) and run ss -ltn on a node to see its host daemons. Those nodes go first.
Get a fixed kernel. Debian, Oracle Linux and Amazon Linux have shipped one, and Red Hat released RHEL 8, 9 and 10 kernels on 1 November. SUSE has covered most products, SLES 15 SP7 included, while its real-time kernels and live patches are still in progress. Ubuntu has shipped nothing so far and lists its releases as work in progress, and Red Hat still lists OpenShift as affected. If you build your own images, build from a fixed stable kernel.
Until then, limit what can reach the bug. Red Hat's security bulletin RHSB-2026-016 has an nftables rule that drops incoming IPv4 TCP packets with IP options. Red Hat's own wording is that it reduces exposure but cannot fully prevent exploitation and is no substitute for patching. On Kubernetes it covers less. Red Hat says a rule on a node only acts on traffic through the node's host network namespace: traffic inside the cluster network, pod to pod included, is not filtered, and whether outside traffic forwarded to pods is filtered depends on the network setup. The kernel CVE team names request-socket migration (net.ipv4.tcp_migrate_req=1 or a reuseport BPF program) as a second way to trigger the bug, so leave that off.
Rebuild or patch the node image, and update the template your autoscaler or provisioning tool uses, or new nodes will keep coming up on the old kernel.
Roll the nodes one by one: kubectl drain, reboot or replace, kubectl uncordon. Respect your PodDisruptionBudgets, and on the control plane wait for etcd to be healthy before touching the next node.
Run kubectl get nodes -o wide again. A node with the package installed but no reboot is still on the old kernel.
Keep the evidence for your auditor: the kernel list before and after, the advisory, a scanner report showing the CVE closed, the change ticket, and a dated risk decision covering the days in between.

How Syself Autopilot fixed CVE-2026-98432

We rescan every supported Syself Autopilot release daily against OSV, NVD and the distribution trackers. Each finding is matched to the exact component build in the release SBOM and tagged with its CISA KEV status and EPSS score. One VEX decision, a written verdict on whether the CVE affects that build, covers every Cluster Stack release that ships the build.

Our security team of experts assesses each finding for the Syself Autopilot environment, with AI-assisted analysis. They check the attack vector against how the platform exposes the component, rescore the severity for the platform, and write down why. The decision and the reasoning behind it are published on the Version Hub; you don't need to be a customer to read them.

For this CVE the older 1.36 releases are marked affected with severity high, and 1.36 v8 is named as the first release with the fix. The published statement reads:

A remote attacker could crash the node or corrupt kernel memory by sending a specially crafted connection-setup packet to a service the node publishes on the network. A newer release of this cluster stack ships a kernel that fixes the flaw.

Syself Autopilot 1.36 v8 shipped on 28 October 2026 with kernel 6.18.59 and Kubernetes 1.36.6. Because nodes run a hardened, immutable OS, a kernel fix arrives as a new release and gets tested as a whole. The upgrade replaces every node from the new image, the control plane one node at a time and then each worker pool node by node. Nothing happens until you point the cluster at the new release. After that it runs through on its own. The work from the list above is done for you, and the evidence your auditor will ask for is already on the Version Hub.

The hub severity is our assessment for this environment rather than the upstream score. For this CVE we rate it high: the attacker has to win a race, which is the attack complexity reading SUSE, Oracle and Amazon also chose, and nobody has reported exploitation in the wild. A CISA KEV listing would move it, like any finding, to critical.

How to check the CVE status of your release on the Version Hub

Open a release on the Version Hub and find the component row, which names the exact build. Each CVE listed there has a VEX status (affected, not_affected with a justification, fixed, or under_investigation), the hub severity described above, and the fix release if there is one. The same page has the SPDX 3.0.1 SBOM, the OpenVEX and CSAF 2.0 advisories, and a machine-readable feed your own tooling can poll.

Security evidence per release explains each file and what it proves, and Meet compliance requirements maps that evidence to ISO 27001, BSI C5, SOC 2 and the CIS Kubernetes Benchmark.

CVE-2026-98432 and MPTCP: what Anthropic and the Go team reported

Anthropic reported on 27 October 2026 that an unreleased internal research model, after initial prompting, wrote an exploit for CVE-2026-98432. Against a server with a multipath TCP (MPTCP) listener it gives a remote attacker root: about 48 minutes to leak a kernel address, then about five more to get a shell. Anthropic has not published the exploit and does not say whether plain TCP is exploitable. Red Hat's bulletin RHSB-2026-016 says MPTCP is not required for the flaw.

The Go security team followed on 29 October 2026: Go 1.24 and later open Linux listeners with MPTCP enabled by default. They describe turning it off with GODEBUG=multipathtcp=0 as a fragile stopgap and point to a patched kernel as the only real fix.

CVE-2026-98432 FAQ

Do Kubernetes nodes need a reboot to fix CVE-2026-98432?

A node only runs the new kernel after a reboot, or after being replaced from an image that has it, unless your vendor offers live patching. On Syself Autopilot you don't reboot anything: upgrading to 1.36 v8 or later replaces every node with one already running the fixed kernel.

Does the Hetzner load balancer protect Kubernetes nodes from CVE-2026-98432?

For traffic that goes through it, yes. The Hetzner Cloud Load Balancer terminates the client's connection and opens its own to your node, so on that path the attacker's packets never reach your node's kernel. Anything the node answers directly on its public address, a NodePort or hostPort for example, still does.

Is CVE-2026-98432 only exploitable with multipath TCP (MPTCP)?

Not necessarily. Anthropic's exploit targeted an MPTCP listener, but Red Hat's bulletin says MPTCP is not a required condition for the flaw, and the Go security team adds that systems without MPTCP listeners may be open to similar attacks. Anthropic has not said whether plain TCP is exploitable, so a node with a vulnerable kernel should be treated as affected either way.

Does CVE-2026-98432 affect IPv6?

Not through the main race. The kernel CVE team notes that the IPv6 code path copies the options instead of sharing them. Dual-stack nodes still answer IPv4, though, so they need the kernel update like everything else.

Which Linux kernel version fixes CVE-2026-98432?

Kernel commit e3f33b0a1d89. It shipped first in the stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distribution kernels have their own version numbers, so check the vendor advisory.

Is CVE-2026-98432 exploited in the wild?

As of 3 November 2026 it is not in the CISA Known Exploited Vulnerabilities catalog, and we have found no public report of exploitation. Anthropic has not published its exploit.

Which Syself Autopilot release fixes CVE-2026-98432, and how do I get it?

Syself Autopilot 1.36 v8, released on 28 October 2026 with Linux kernel 6.18.59, is the first release with the fix. Release 1.36 v9, from 3 November 2026, ships the same kernel. Point the cluster at the release when it suits you; how cluster upgrades work covers ordering, timing and availability.