Linux-Lücke CVE-2026-98432: Bin ich betroffen? So prüfst Du Ubuntu, Debian und Raspberry Pi OS

Handeln musst Du jetzt, wenn ein Linux-Rechner von Dir aus dem Internet per IPv4 und TCP erreichbar ist. Das gilt für VPS und Root-Server, für Homeserver mit Portfreigabe und für jeden Raspberry Pi, auf den ein Port im Router zeigt. Gelassen bleiben kannst Du mit einem Desktop oder Laptop hinter dem Router ohne Portfreigabe. Dort reicht es, das Kernel-Update einzuspielen und neu zu starten, sobald es kommt.

Der Stand am Sonntag, 1. November 2026: Debian, Fedora und Arch liefern bereits einen reparierten Kernel. Ubuntu, Red Hat und der normale Kernel von Raspberry Pi OS haben noch keinen. Angriffe sind bisher nicht bekannt. Bis das Update kommt, hilft eine kurze nftables-Regel. Unten findest Du die Prüfbefehle, den Patchstand je Distribution und eine Entscheidungshilfe.

Was hinter CVE-2026-98432 steckt

Der Fehler sitzt im Kernel, genauer in dem Code, der neue IPv4-TCP-Verbindungen annimmt. Will ein Gerät eine Verbindung zu Deinem Server aufbauen, schickt es zuerst ein SYN-Paket. Darin darf es IP-Optionen mitsenden, etwa Record Route oder Timestamp. Der Kernel merkt sich diese Optionen für seine Antwort.

Der Angreifer öffnet eine solche Verbindung und schickt das SYN kurz danach ein zweites Mal. Ein Prozessorkern beantwortet die Wiederholung und liest dabei die gespeicherten Optionen. Ein anderer Kern hat die Verbindung inzwischen fertig aufgebaut, wieder abgebaut und den Speicher sofort freigegeben. Der erste Kern arbeitet dann mit Speicher, der schon frei ist. Fachleute nennen das Use-after-free. Im schlimmsten Fall verrät der Kernel dabei Speicherinhalte, schreibt an falsche Stellen oder stürzt ab.

Der fehlerhafte Code kam mit Linux 4.4 Anfang 2016 in den Kernel. Gemeldet hat ihn Xinyang Ge, ein Forscher bei Anthropic. Den Fix schrieb Kernel-Entwickler Eric Dumazet Anfang Oktober. Der Kernel gibt den Speicher jetzt erst frei, wenn kein anderer Kern mehr darauf zugreift. Am 15. Oktober bekam der Fehler die Kennung CVE-2026-98432. Das Kernel-CVE-Team bewertet ihn mit 9,8 von 10 Punkten. Red Hat hatte zunächst niedriger eingestuft und nennt die Lücke seit dem 30. Oktober ebenfalls kritisch.

Brisant macht die Lücke ein Detail aus dem Bericht von Anthropic. Verliert der Angreifer das Wettrennen, scheitert nur dieser eine Verbindungsaufbau. Das System läuft weiter, er kann es also beliebig oft versuchen. Im Versuch von Anthropic dauerte es 48 Minuten, bis ein Kernel-Zeiger bekannt war. Weitere fünf Minuten später lief ein Befehl mit Root-Rechten. Den Exploit hat Anthropic nicht veröffentlicht. IPv6 ist vom Hauptfehler nicht betroffen, weil der Kernel die Optionen dort kopiert.

Wer wirklich gefährdet ist

Die Lücke greift vor jeder Anmeldung. Ein starkes Passwort, ein SSH-Schlüssel oder ein Login-Formular schützen Dich also nicht. Entscheidend ist allein, ob ein Angreifer ein SYN-Paket an einen offenen TCP-Port Deines Rechners schicken kann.

Jeder per IPv4-TCP erreichbare Dienst

Grundsätzlich reicht ein lauschender TCP-Dienst, den der Angreifer per IPv4 erreicht. Das kann der SSH-Server sein, ein Webserver, ein Reverse-Proxy oder Deine Nextcloud. Ob sich der Fehler ohne MPTCP bis zur Codeausführung treiben lässt, hat bisher niemand öffentlich gezeigt. Speicher beschädigen oder den Rechner abstürzen lassen kann er laut der Bewertung des Kernel-Teams aber auch so. Das Go-Sicherheitsteam schreibt ausdrücklich, dass der Fehler nicht an MPTCP hängt.

Ein Rechner, der nur selbst nach außen verbindet, bietet diesen Angriffspunkt nicht. Surfen, Mails abrufen oder Updates laden öffnen keinen lauschenden Port. Wichtig ist nur, ob ein Dienst auf einer Adresse lauscht, die von außen erreichbar ist.

Am höchsten ist das Risiko mit MPTCP

Den Root-Exploit hat Anthropic gegen einen Server mit MPTCP-Listener gezeigt. MPTCP steht für Multipath TCP. Damit kann eine Verbindung mehrere Wege gleichzeitig nutzen, etwa WLAN und Mobilfunk. Ein Programm muss MPTCP beim Öffnen des Sockets ausdrücklich anfordern.

Genau das tun Go-Programme seit Go 1.24 von selbst. Laut den Release Notes nutzen ihre Listener unter Linux standardmäßig MPTCP, wenn der Kernel es erlaubt. Viele Selfhosting-Werkzeuge sind in Go geschrieben, zum Beispiel Caddy, Traefik, Syncthing und AdGuard Home. Ob ein bestimmtes Programm wirklich per MPTCP lauscht, hängt davon ab, wie es gebaut wurde. Verlass Dich deshalb nicht auf Listen, sondern prüf es mit dem Befehl weiter unten.

Auch tailscaled, der Dienst hinter Tailscale, ist ein Go-Programm. Nutzer berichten, dass er auf seiner Tailscale-Adresse per MPTCP lauscht. Diese Adresse erreichen allerdings nur Geräte aus Deinem eigenen Tailnet. Wie Du Tailscale aufsetzt und verwaltest, steht in unserer Tailscale-Anleitung für Einsteiger.

Ubuntu 26.04, Debian und Raspberry Pi OS erlauben MPTCP

Ob der Kernel MPTCP-Sockets zulässt, regelt der Schalter net.mptcp.enabled. Der Kernel setzt ihn ab Werk auf 1. Ubuntu, Debian und Raspberry Pi OS bauen MPTCP fest in ihre Kernel ein, damit gilt dort normalerweise dieser Standard. Für Ubuntu 26.04 berichten Tester das auch ausdrücklich. Bist Du gerade auf die neue LTS umgestiegen, findest Du die übrigen Änderungen in unserem Beitrag zu Ubuntu 26.04 LTS mit Neuerungen und Upgrade-Anleitung. RHEL, AlmaLinux und Rocky Linux schalten MPTCP dagegen ab Werk ab.

Ein eingeschalteter Schalter allein ist noch kein Problem. Heikel wird es erst, wenn ein Programm auch wirklich per MPTCP lauscht und von außen erreichbar ist.

Patchstand je Distribution am 1. November 2026

Die Tabelle zeigt, was die Distributionen am Abend des 1. November ausgeliefert haben. Bei Ubuntu stehen die Versionen, in denen der Fix laut Tracker gerade vorbereitet wird.

Die Ubuntu-Versionen können sich bis zur Freigabe noch ändern. Den aktuellen Stand zeigen der Ubuntu-Tracker und der Debian-Tracker. Einen Termin für Ubuntu oder RHEL nennt bisher niemand.

Linux Mint 22.x baut auf Ubuntu 24.04 auf und bekommt dessen Kernel. Mint 22.2 und 22.3 bringen ab Werk den HWE-Kernel 6.14 mit. Für diese Serie liefert Ubuntu keine Updates mehr. Läuft bei Dir noch 6.14, wechsle in der Aktualisierungsverwaltung im Bereich Linux-Kernel auf eine gepflegte Serie. Sonst kommt der Fix bei Dir nie an. Wer gerade erst von Windows kommt, findet die Grundlagen in unserem Plan Von Windows 10 auf Linux Mint wechseln.

So prüfst Du Deinen Rechner in fünf Schritten

Die folgenden Befehle laufen im Terminal und ändern nichts am System. Arbeite sie auf jedem Rechner ab, der von außen erreichbar ist.

1. Welcher Kernel läuft gerade?

uname -r

Die Ausgabe zeigt den laufenden Kernel, nicht den zuletzt installierten. Auf einem Raspberry Pi mit Trixie steht dort zum Beispiel 6.18.50+rpt-rpi-v8. Das ist noch die alte Version, der Fix beginnt bei 6.18.56. Unter Fedora und Arch vergleichst Du die Nummer ebenfalls direkt mit der Tabelle.

2. Steckt der Fix im Kernel?

Debian und Ubuntu übertragen Fixes in ihre eigenen Kernel. Die Versionsnummer sieht deshalb älter aus, als der Code ist. Unter Debian zeigt Dir dieser Befehl die Paketversion des laufenden Kernels:

uname -v

Steht dort Debian 6.1.190-1 (Debian 12), Debian 6.12.113-1 (Debian 13) oder eine höhere Version, ist der Fix drin. Unter Ubuntu und Linux Mint durchsuchst Du das Changelog des laufenden Kernels nach der CVE-Nummer:

zgrep -c CVE-2026-98432 /usr/share/doc/linux-modules-$(uname -r)/changelog.Debian.gz

Eine 0 bedeutet, dass der laufende Kernel den Fix noch nicht enthält. Mit Internetverbindung klappt es auch über apt:

apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

Unter RHEL, AlmaLinux und Rocky Linux fragst Du das Changelog des RPM-Pakets ab:

rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

Bei AlmaLinux kannst Du auch die Version vergleichen. Die Testing-Kernel tragen die Nummern 4.18.0-553.180.2.el8_10, 5.14.0-687.61.2.el9_8 und 6.12.0-211.69.2.el10_2.

3. Welche Dienste lauschen auf IPv4-TCP?

sudo ss -tlnp4

Schau auf die Spalte Local Address. Steht dort 127.0.0.1, ist der Dienst nur auf dem Rechner selbst erreichbar. Bei 0.0.0.0 oder einer öffentlichen Adresse nimmt er Verbindungen von außen an, soweit Router und Firewall sie durchlassen. Ganz rechts steht das Programm, das den Port geöffnet hat.

4. Gibt es MPTCP-Listener?

sysctl net.mptcp.enabled
sudo ss -H -lMnp

Zeigt sysctl den Wert 0, kann kein Programm MPTCP-Sockets öffnen. Gibt es den Schlüssel gar nicht, hat Dein Kernel kein MPTCP. Bleibt die Ausgabe von ss leer, lauscht gerade nichts per MPTCP. Jede Zeile steht dagegen für einen MPTCP-Listener samt Programm. Meldet ss einen Fehler bei der Option -M, ist Dein iproute2 zu alt für diese Prüfung.

Beachte bei Docker: ss sieht nur die Sockets des Hosts. Container haben eigene Netz-Namensräume. Einen einzelnen Container prüfst Du so, wobei Du NAME durch den Containernamen ersetzt:

sudo nsenter -t $(docker inspect -f '{{.State.Pid}}' NAME) -n ss -H -lMn

5. Wartet ein Neustart?

ls /var/run/reboot-required

Ubuntu legt diese Datei an, wenn ein Update einen Neustart braucht. Unter Debian und Raspberry Pi OS ist sie nicht verlässlich. Dort hilft das Paket needrestart mit sudo needrestart -k. Unter RHEL und AlmaLinux zeigt sudo needs-restarting -r, ob ein Neustart fällig ist. Ganz ohne Werkzeug vergleichst Du uname -r mit dem neuesten Kernel unter /boot.

Notlösungen, bis der Kernel kommt

Für Ubuntu, RHEL und den Pi gibt es heute nichts Fertiges zu installieren. Die drei folgenden Maßnahmen senken das Risiko bis dahin. Keine davon ersetzt das Kernel-Update.

nftables-Regel gegen IPv4-TCP mit IP-Optionen

Der Angriff braucht ein SYN-Paket mit IP-Optionen. Normaler TCP-Verkehr trägt so gut wie nie IPv4-Optionen, seine eigenen Optionen stehen im TCP-Kopf. Wirft der Rechner solche Pakete früh weg, erreicht der Auslöser den verwundbaren Code nicht. Ohne Optionen ist der IPv4-Kopf genau 20 Byte lang. Das entspricht dem Wert 5 im Feld hdrlength, alles darüber trägt Optionen. AlmaLinux veröffentlicht dafür diese Regel, sie funktioniert auch unter Debian, Ubuntu und Raspberry Pi OS:

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

Fehlt der Befehl nft, installierst Du ihn mit sudo apt install nftables. Die Regel nutzt eine eigene Tabelle und kommt Regeln von ufw, firewalld oder Docker deshalb nicht in die Quere. Weil sie schon in prerouting greift, erfasst sie auch Pakete, die der Host an Docker-Container mit veröffentlichten Ports weiterreicht. Ob sie arbeitet, zeigt der Zähler. Den zweiten Befehl brauchst Du erst, wenn der neue Kernel läuft:

sudo nft list table ip cve_2026_98432
sudo nft delete table ip cve_2026_98432

Die Regel hat Grenzen, die Du kennen solltest:

• Sie überlebt keinen Neustart. Startest Du vor dem Kernel-Update neu, setz sie erneut.
• Aktiviere dafür nicht einfach den Dienst nftables. Seine Standard-Konfiguration beginnt mit flush ruleset und löscht beim Laden auch die Regeln von ufw oder Docker.
• Verkehr zwischen Containern auf demselben Host kann an ihr vorbeilaufen.
• Arbeitet der Rechner als Router, verwirft sie auch weitergeleitete TCP-Pakete mit IPv4-Optionen.
• Netze mit CIPSO-Sicherheitslabels (NetLabel) brauchen IPv4-Optionen. Dort setzt Du die Regel nicht ein.

Red Hat empfiehlt im Bulletin RHSB-2026-016 eine fast gleiche Regel und sagt klar, was sie leistet: Sie verringert das Risiko, verhindert einen Angriff aber nicht vollständig. Die Hintergründe zur Variante von AlmaLinux stehen im Beitrag von AlmaLinux.

MPTCP im Kernel abschalten

Die meisten Homeserver brauchen MPTCP nicht. Dann schaltest Du es im Kernel ab:

sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-no-mptcp.conf

Der erste Befehl wirkt sofort, die Datei hält die Einstellung über den Neustart hinaus. Laut Kernel-Dokumentation regelt der Schalter nur, ob neue MPTCP-Sockets entstehen dürfen. Starte deshalb Dienste neu, die schon per MPTCP lauschen, und prüf danach erneut mit ss. Go-Programme fallen dann auf normales TCP zurück. Der Schalter gilt außerdem nur für den Netz-Namensraum des Hosts, Docker-Container behalten ihren eigenen Wert. Dieser Schritt nimmt dem gezeigten Exploit seine Voraussetzung. Den Fehler im normalen TCP-Code beseitigt er nicht.

Go-Programme mit GODEBUG=multipathtcp=0

Das Go-Sicherheitsteam nennt eine Abhilfe pro Programm, die Umgebungsvariable GODEBUG=multipathtcp=0. Bei einem systemd-Dienst setzt Du sie per Drop-in, hier am Beispiel von Caddy:

sudo systemctl edit caddy

Im Editor trägst Du diese zwei Zeilen ein, speicherst und startest den Dienst neu:

[Service]
Environment=GODEBUG=multipathtcp=0

sudo systemctl restart caddy

Für tailscaled oder andere Go-Dienste gehst Du genauso vor. In Docker Compose setzt Du die Variable im Abschnitt environment des Containers. Das Go-Team nennt diese Abhilfe selbst fragil. Ein einziger vergessener MPTCP-Listener lässt das System offen, und Programme können die Einstellung im Code übergehen. Außerdem setzt sie voraus, dass jeder Angriff MPTCP braucht.

Kernel-Update einspielen und neu starten

Sobald Deine Distribution den Fix ausliefert, ist er die eigentliche Lösung. Ein neuer Kernel wirkt erst nach dem Neustart.

# Debian, Ubuntu, Linux Mint, Raspberry Pi OS
sudo apt update && sudo apt full-upgrade

# Fedora, RHEL, AlmaLinux, Rocky Linux
sudo dnf upgrade --refresh

# Arch Linux
sudo pacman -Syu

# danach bei allen
sudo reboot

Prüf nach dem Neustart mit uname -r und dem Changelog-Befehl, ob der neue Kernel wirklich läuft. Danach entfernst Du die nftables-Regel wieder. Bei AlmaLinux liegt der Kernel derzeit im Testing-Repository. Wie Du ihn von dort holst, beschreibt AlmaLinux im verlinkten Beitrag.

Spielst Du Updates automatisch ein, bleibt der Neustart trotzdem Deine Aufgabe. Auf dem Pi ist noch ein Detail wichtig: Der Kernel kommt aus dem Repository von Raspberry Pi, nicht von Debian. Wie Du unattended-upgrades so einrichtest, dass es diese Pakete mitnimmt, zeigt unsere Anleitung zu automatischen Updates bei Raspberry Pi OS.

Raspberry Pi: warten oder Vorabkernel?

Für Raspberry Pi OS gibt es den reparierten Kernel bisher nur als Vorabversion. Ein Raspberry-Pi-Entwickler nennt im offiziellen Forum den Kernel 6.18.59 aus rpi-update. Über apt kommt dagegen noch 6.18.50. Im Repository liegt 6.18.59 inzwischen auch im Beta-Zweig für Trixie, für Bookworm gibt es dort noch nichts. DietPi baut keine eigenen Pi-Kernel und wartet ebenfalls auf Raspberry Pi.

Die offizielle Dokumentation empfiehlt rpi-update nur für Tests oder wenn Raspberry-Pi-Entwickler ausdrücklich dazu raten. Steht Dein Pi hinter dem Router ohne Portfreigabe, wartest Du einfach auf das normale Update. Hängt er per Portfreigabe im Netz, setz jetzt die nftables-Regel und schalte MPTCP ab. Willst Du den Vorabkernel trotzdem, sichere vorher die Speicherkarte oder SSD und starte danach neu:

sudo rpi-update
sudo reboot

Die zweite Kernel-Baustelle: Fragnesia

Parallel taucht eine ältere Kernel-Lücke wieder in den Meldungen auf. Fragnesia (CVE-2026-46300) ist eine lokale Rechteausweitung in der IPsec-Verarbeitung des Kernels (ESP-in-TCP). Wer schon Code auf dem Rechner ausführen kann, wird damit root. Die Lücke ist seit Mai öffentlich, samt Exploit für Kernel vor dem 13. Mai 2026. Debian und Ubuntu haben sie seitdem gepatcht. Das Kernel-Team bewertet sie mit 7,8 Punkten.

Neu ist die Kette. Angreifer nutzen die PHP-Lücken PHP2Shell (CVE-2026-109618 und CVE-2026-109619), um eine Webshell abzulegen. Mit Fragnesia machen sie sich dann zu root. Die US-Behörde CISA hat Fragnesia deshalb am 28. Oktober in ihren Katalog aktiv ausgenutzter Lücken aufgenommen. CVE-2026-98432 steht dort bisher nicht. Für Dich heißt das: Ein Kernel, der seit Mai nie aktualisiert und neu gestartet wurde, ist doppelt verwundbar. Betreibst Du WordPress, Nextcloud oder eine andere PHP-Anwendung, bringst Du PHP und Kernel jetzt gemeinsam auf den aktuellen Stand.

Entscheidungshilfe: Was Du jetzt tun solltest

Was feststeht, was aussteht und was offen ist

• Gilt jetzt: Der Fix steckt seit Mitte Oktober in allen gepflegten Stable-Zweigen des Kernels. Debian, Fedora und Arch liefern ihn aus. Angriffe in freier Wildbahn sind bis zum 1. November nicht bekannt.
• Steht aus: Kernel für alle Ubuntu-Versionen, für RHEL 8 bis 10 und Rocky Linux sowie der reguläre apt-Kernel für Raspberry Pi OS. AlmaLinux testet seine Kernel noch. Ein Datum nennt keiner der Hersteller.
• Unklar: Ob Angreifer ohne MPTCP-Listener ebenfalls Root-Rechte erreichen. Welche Kernelversion und Konfiguration Anthropic getestet hat. Und wann jemand den Angriff nachbaut.

Häufige Fragen

Mein Rechner steht zu Hause hinter dem Router, ohne Portfreigabe. Muss ich etwas tun?

Kaum. Ohne Portfreigabe nimmt der Router SYN-Pakete aus dem Internet gar nicht erst an. Angreifen könnte Dich nur ein Gerät aus Deinem eigenen Netz, etwa ein gekapertes Smart-Home-Gerät. Schau im Router trotzdem kurz nach, ob Programme per UPnP selbst Ports geöffnet haben. Das zählt wie eine Portfreigabe. Ansonsten spielst Du das Kernel-Update ein, sobald es kommt, und startest neu.

Mein Raspberry Pi hat eine Portfreigabe. Was jetzt?

Dann gehört er zu den Geräten, die Du heute absicherst. Setz die nftables-Regel, schalte MPTCP ab und prüf mit ss, welche Dienste von außen erreichbar sind. Brauchst Du die Freigabe nur für den Zugriff von unterwegs, ist ein Tunnel ohne offenen TCP-Port die bessere Lösung. WireGuard läuft über UDP, Tailscale kommt ganz ohne Portfreigabe aus. Danach wartest Du auf das reguläre Kernel-Update oder nimmst den Vorabkernel.

Sind Docker-Container betroffen?

Ja, über den Host. Container bringen keinen eigenen Kernel mit, sie nutzen den des Hosts. Ein neues Image ändert an der Lücke deshalb nichts. Der Host braucht den Fix und einen Neustart. Bis dahin deckt die nftables-Regel auf dem Host auch veröffentlichte Container-Ports ab. Docker Desktop unter Windows und macOS sowie WSL2 laufen mit einem eigenen Linux-Kernel, der mit deren Updates kommt.

Hilft ein VPN gegen die Lücke?

Nein. Ein solcher Tunnel verschlüsselt Deine Verbindungen, er repariert aber keinen Kernel. Lauscht auf dem Rechner ein Dienst, der über den Tunnel oder eine Portweiterleitung erreichbar ist, bleibt er genauso angreifbar. Das gilt auch für einen Pi, der als Router für den Tunnel arbeitet, wie in unserer Anleitung Raspberry Pi als VPN-Router mit RaspAP. Er braucht den Kernel-Fix wie jeder andere Pi.

So gehst Du jetzt vor

Nimm Dir heute jeden Linux-Rechner vor, der von außen erreichbar ist. Prüf Kernel, Changelog, offene Ports und MPTCP-Listener. Debian, Fedora und Arch aktualisierst Du sofort und startest neu. Auf Ubuntu, RHEL und dem Pi setzt Du die nftables-Regel, schaltest MPTCP ab und spielst den Kernel ein, sobald er im normalen Repository liegt. Den Desktop hinter dem Router erledigst Du mit dem nächsten regulären Update samt Neustart.