Kritische Linux-Lücke im TCP-Code: Was Server-Betreiber jetzt tun sollten

Im Linux-Kernel steckt eine kritische Lücke, die aus dem Netz ohne Anmeldung erreichbar ist. CVE-2026-98432 hat eine CVSS-Bewertung von 9.8 und betrifft laut heise online alle IPv4-Implementierungen seit Kernel 4.4. Angriffe sind bisher nicht bekannt. Debian hat Updates ausgeliefert, bei Ubuntu und Red Hat fehlten sie zuletzt noch. Stand dieses Beitrags ist der 31. Oktober 2026.

Der Fehler sitzt im Aufbau von TCP-Verbindungen

Die Lücke ist ein Use-after-free. Der Kernel greift also auf bereits freigegebenen Speicher zu. AlmaLinux beschreibt den Auslöser so: Ein SYN-Paket mit IPv4-Optionen geht an einen lauschenden TCP-Port. Wiederholt der Client dieses Paket, kann ein anderer CPU-Kern gerade die Antwort aus denselben Optionen bauen, während deren Speicher schon freigegeben wird. Normaler Verkehr nutzt solche IP-Optionen selten.

Red Hat nennt Systeme, die eingehende TCP-Verbindungen annehmen, als am stärksten gefährdet. AlmaLinux formuliert es ähnlich: Jedes System, das IPv4-TCP-Verbindungen aus nicht vertrauenswürdigen Netzen annimmt, gilt als exponiert. Das trifft auf Webserver zu, also auch auf Server, auf denen ein Shop läuft. IPv6 ist vom Hauptproblem nicht betroffen, für eine ähnliche Schwachstelle bei der Socket-Migration soll laut Ubuntu ein eigener Patch folgen.

Wie gefährlich die Lücke praktisch ist, bleibt umstritten

Die Bewertung liegt bei 9.8, die Folgen beschreiben die Quellen unterschiedlich. Red Hat nennt als Hauptfolge einen Systemabsturz und möglicherweise Speicherkorruption. Für zuverlässige Codeausführung braucht ein Angreifer laut Red Hat eine präzise Kontrolle über den Heap, Red Hat bezeichnet die CVSS-Werte zudem als vorläufig. Das zugehörige Bulletin spricht von möglicher Remote Code Execution.

Der einzige bekannte Exploit stammt laut heise von Anthropic und ist nicht öffentlich. Er bezieht sich auf Multipath-TCP-Verbindungen (MPTCP). Das Kernel-Team von CloudLinux meldet, es habe die Behauptung eines Root-Zugriffs aus der Ferne nicht reproduzieren können. Ob auf dem Zielsystem ein MPTCP-Dienst laufen muss, ist laut heise unklar. Der Fehler liegt laut AlmaLinux und CloudLinux aber im regulären TCP-Code, deshalb brauchen auch Server ohne MPTCP das Update.

Auch die Folgen eines Fehlversuchs sehen die Quellen nicht gleich. Red Hat warnt vor Abstürzen, die einen Shop offline nehmen würden. CloudLinux schreibt dagegen, ein Fehlversuch koste den Angreifer nur eine Verbindung und der Server laufe weiter.

Der Patch ist da, aber nicht überall

Im Kernel selbst ist der Fehler in den Versionen 6.12.113, 6.18.56, 7.2.10 und 7.3-rc7 behoben. Für Ihren Server zählt aber der Stand Ihrer Distribution:

• Debian: Der Security-Tracker nennt für trixie die Version 6.12.113-1 (DSA-6568-1). Für bookworm sind es 6.1.190-1 (DLA-4841-1) und beim 6.12-Kernel 6.12.113-1~deb12u1 (DLA-4850-1).
• Ubuntu: Die Ubuntu-Seite führte das Paket linux zuletzt noch als verwundbar, die Fixes sind in Arbeit: 7.0.0-43.43 für 26.04 LTS, 6.8.0-149.149 für 24.04 LTS und 5.15.0-203.213 für 22.04 LTS. Für 20.04, 18.04 und 16.04 LTS nannte die Seite keine Fix-Version.
• Red Hat: RHEL 8, 9 und 10 sowie OpenShift sind betroffen. Das Bulletin RHSB-2026-016 kündigt beschleunigte Fixes an, nennt aber noch keine Errata oder Kernel-Versionen.
• AlmaLinux: Gepatchte Kernel liegen im Testing-Repository, etwa kernel-5.14.0-687.61.2.el9_8 für AlmaLinux 9. Sie sollen nach dem Test in die regulären Repositories wandern.
• CloudLinux: Version 7 ist laut CloudLinux nicht betroffen. Für 7h und 8 läuft der Rollout des Fix-Kernels, ein Livepatch ist in Vorbereitung.

Den aktuellen Stand nennen die Seiten Ihrer Distribution. Welcher Kernel läuft, zeigt uname -r. AlmaLinux rät, nach der Installation neu zu starten, denn bis dahin läuft der alte Kernel weiter.

Bis zum Update kann eine Firewall-Regel das Risiko senken

Red Hat veröffentlicht eine nftables-Regel, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft. Sie wird in einer Datei cve-2026-98432.nft abgelegt:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Eingespielt wird sie laut Red Hat mit diesen Befehlen:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Die Regel verringert das Risiko, schließt die Lücke aber nicht. Red Hat warnt, dass sie benötigte Dienste stören kann, und rät, sie zuerst in einer Testumgebung auszuprobieren. AlmaLinux veröffentlicht eine ähnliche Regel und nennt dafür weitere Grenzen. Verkehr zwischen Containern auf demselben Host kann sie umgehen, nach einem Neustart ist sie weg, und für Netze mit CIPSO-Labels taugt sie nicht. CloudLinux nennt für seine Systeme gar keine Abhilfe außer Kernel-Update oder Livepatch.

Zusätzlich empfiehlt AlmaLinux, MPTCP zu prüfen: sysctl net.mptcp.enabled sollte 0 ausgeben. Steht dort 1 und Sie brauchen MPTCP nicht, lässt es sich abschalten. Go-Anwendungen setzen MPTCP laut heise standardmäßig. Nach dem Kernel-Update entfernen Sie die Regel mit sudo nft delete table inet cve_2026_98432.

Wir aktualisieren den Kernel und planen den Neustart mit Ihnen

Die Lücke kommt kurz nach php2shell und Fragnesia. Wer diese beiden Beiträge schon abgearbeitet hat, muss für CVE-2026-98432 trotzdem einen neuen Kernel einspielen. Bei unseren Managed Servern spielen wir Kernel-Updates ein und planen den Neustart mit Ihnen.

Wenn Sie nicht sicher sind, welcher Kernel auf Ihrem Shop-Server läuft, schreiben Sie uns.