CVE-2026-98432: Linux Kernel Flaw Exposing KrakenD on Unpatched Hosts

CVE-2026-98432 is a critical use-after-free in the IPv4 TCP stack of the Linux kernel (CVSS 9.8) that a remote, unauthenticated attacker can reach by sending packets to any listening port. It is not a KrakenD vulnerability and no KrakenD release can fix it. Still, KrakenD runs on the kernel of your host, and its default listener matches the conditions of the public remote root exploit. Patch the kernel of every host or node running KrakenD, and set GODEBUG=multipathtcp=0 on the gateway until you can.

How the Kernel Vulnerability Works

When the kernel accepts a TCP connection, tcp_v4_syn_recv_sock() hands the IPv4 options of the connection request to the new socket without copying them. A retransmitted SYN carrying IPv4 header options can race with this handoff and make the kernel read freed memory while it builds the SYN-ACK. A similar race exists when request socket migration is enabled (net.ipv4.tcp_migrate_req=1). The upstream fix frees the options only after an RCU grace period.

The bug affects kernels from 4.4 onwards, and the attacker needs no credentials: reaching a listening IPv4 TCP port is enough. A proof of concept described on oss-security achieves remote code execution as root, and it requires the target port to be an MPTCP listener. The race itself is not specific to MPTCP, though. Nobody has shown a remote code execution path without MPTCP so far, and the Go team advises against assuming it is impossible.

Why KrakenD Matches the Exploit Conditions

Multipath TCP (MPTCP) is a TCP extension that lets a single connection use several network paths at once. Since Go 1.24, Go programs on Linux open their listening sockets as MPTCP by default, while outgoing connections stay plain TCP. The Go team does not plan to change this default for now (golang/go#82717).

KrakenD is a Go program. We verified that KrakenD EE 3.0.2, built with Go 1.26.10, listens on port 8080 with an MPTCP socket in its default configuration. Clients that do not request MPTCP, which is nearly all of them, still get plain TCP connections, but the exploit only needs the listening socket to be MPTCP. The same default applies to every listener in the process, such as port 8090 or listeners opened by custom plugins.

We only tested KrakenD EE 3.0.2. Other KrakenD versions built with Go 1.24 or later, Community or Enterprise, are likely in the same situation. Containers share the kernel of the host, so updating the KrakenD image does not protect you.

Check Whether Your Deployment Is Exposed

A KrakenD deployment matches the published exploit when two conditions meet: the kernel of the host or node is unpatched, and KrakenD listens on an MPTCP socket.

Check the kernel of each host or node (uname -r) against the security advisory of your distribution for CVE-2026-98432. The upstream stable kernels that include the fix are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, plus the 7.3 mainline. Distributions backport fixes under their own version numbers, so rely on your vendor’s advisory rather than on comparing numbers.

To see the socket type, run ss -Mltn inside the network namespace of the KrakenD container. With Docker, you can enter it from the host:

$sudo nsenter -t $(docker inspect -f '{{.State.Pid}}' krakend) -n ss -Mltn

On Kubernetes, run the same command from a debug container that shares the network of the pod, using any image that ships ss. Replace KRAKEND_POD with the name of your pod:

$kubectl debug -it KRAKEND_POD --image=nicolaka/netshoot -- ss -Mltn

An mptcp line in LISTEN state for port 8080, or any other KrakenD port, means the gateway uses MPTCP listeners. Once you apply the mitigation below, the output shows tcp lines only.

Patch the Host Kernel

Updating the kernel of every host and node running KrakenD to a fixed version is the only complete solution, and it protects every other service on those machines too. On managed Kubernetes, check the security bulletin of your provider for the node image that includes the fix, and upgrade your node pools.

Disable MPTCP in KrakenD Until You Patch

While you roll out the kernel update, tell the Go runtime to open plain TCP listeners by setting the GODEBUG environment variable to multipathtcp=0. We verified it on KrakenD EE 3.0.2: the gateway starts, serves traffic, and listens on plain TCP only. The setting blocks the published MPTCP exploit path but does not remove the kernel bug, so treat it as a stopgap.

With Docker, pass the variable to docker run:

$docker run -p 8080:8080 -e GODEBUG=multipathtcp=0 -v "$PWD:/etc/krakend/" krakend/krakend-ee:3.0.2

On Kubernetes, add it to the env of the KrakenD container in your Deployment:

env:
  - name: GODEBUG
    value: "multipathtcp=0"

If you already set GODEBUG for another reason, append the new setting with a comma instead of replacing the value, for example GODEBUG=http2debug=0,multipathtcp=0. Run the ss -Mltn check again afterwards to confirm that no mptcp listener remains.

The Go team also suggests dropping inbound IPv4 TCP packets that carry IP options at your firewall or load balancer. Neither the Go team nor we have confirmed that this is sufficient on its own, so use it as an extra layer and not as a replacement for the kernel patch.

Impact of Disabling MPTCP

Disabling MPTCP changes only the type of the listening socket. Your configuration, routing and connections to backends stay the same. The few clients that actually use MPTCP, such as some Apple services, Linux clients running mptcpize, or some carrier proxies, fall back to single-path TCP without errors. The setting applies to the whole process, including listeners opened by custom plugins.

We measured no meaningful performance cost. These are the results of a wrk benchmark against the /__health endpoint, with 32 connections over loopback and three alternating rounds:

The 2% difference on new connections is close to noise, and in real traffic the latency of your backends dominates.

Why This CVE Is Not on the Security Advisories Page

The Security Advisories page tracks vulnerabilities in KrakenD and its dependencies, each with the release that fixes it. CVE-2026-98432 lives in the Linux kernel and no KrakenD release can fix it, so this post is where we document it. If your security team asks about it, the answer is a kernel update, not a KrakenD upgrade.

References

• CVE-2026-98432 on NVD
• CVE-2026-98432 on CVE.org
• oss-security announcement
• Go issue on MPTCP listeners and CVE-2026-98432
• Go team announcement