Ubuntu-Kernel CVE-2026-98432: was Sie jetzt tun müssen

CVE-2026-98432 im Ubuntu-Kernel: die Antwort in drei Schritten

CVE-2026-98432 ist eine kritische Lücke im Netzwerkteil des Linux-Kernels. Der Fix für Ubuntu 22.04, 24.04 und 26.04 liegt seit dem 5. und 6. November 2026 im normalen Update-Kanal -updates. Für die meisten Ubuntu-VPS heißt das: Kernel aktualisieren, neu starten, Version prüfen. Die Umwege über -proposed und die Firewall-Regel brauchen Sie nur, wenn Ihre Kernel-Variante noch wartet.

Dieser Stand gilt für den 7. November 2026. An diesem Tag haben wir die Paketquellen von Ubuntu, den Ubuntu CVE Tracker und das Bulletin von Red Hat gelesen. Ältere Artikel sagen, der Ubuntu-Fix liege nur in -proposed. Das war bis Ende Oktober richtig und ist inzwischen überholt.

Was hinter CVE-2026-98432 steckt

Der Ubuntu CVE Tracker stuft die Lücke als „Critical“ ein. Der CVSS-Wert (Common Vulnerability Scoring System) liegt bei 9.8. Es handelt sich um einen Use-after-free, kurz UAF: Der Kernel gibt Speicher frei, während ein anderer Teil des Codes ihn noch benutzt. Konkret übergibt tcp_v4_syn_recv_sock() die IP-Optionen einer halb offenen IPv4-TCP-Verbindung an den neuen Socket. Gleichzeitig kann ein anderer CPU-Kern dieselben Daten noch für ein SYNACK-Paket brauchen. Der Fix gibt den Speicher deshalb über kfree_rcu() frei. RCU (read-copy-update) wartet, bis kein anderer Kern die Daten mehr liest.

Betroffen ist IPv4. Laut Tracker betrifft dieser erste Fehler IPv6 nicht. Ein verwandtes Problem bei IPv6 soll ein eigener Patch beheben. Außerdem nennt der Tracker die Migration von Request-Sockets (net.ipv4.tcp_migrate_req=1) als Pfad mit einem ähnlichen Fehler.

Der CVSS-Wert von 9.8 steht für einen Angriff über das Netz ohne Anmeldung. Ein Angreifer braucht also kein Konto auf Ihrem Server. Aktualisieren Sie deshalb jeden VPS mit öffentlicher IPv4-Adresse. Verlassen Sie sich nicht darauf, dass auf Ihrem Server kein bestimmter Dienst läuft.

Läuft Ihr VPS überhaupt einen eigenen Kernel?

Diese Frage entscheidet, wer das Update einspielt. Auf einem KVM-VPS bringt die virtuelle Maschine ihren eigenen Kernel mit. Sie aktualisieren ihn selbst und starten selbst neu. Ein Container-VPS (zum Beispiel LXC oder OpenVZ) hat keinen eigenen Kernel. Die LXD-Dokumentation erklärt es so: System-Container nutzen den Kernel des Host-Systems, und mehrere Container teilen sich denselben Kernel. Ein apt upgrade im Container hilft dann nicht. Der Fix hängt am Host Ihres Anbieters.

systemd-detect-virt
uname -r

systemd-detect-virt gibt kvm aus, wenn Sie in einer KVM-Maschine arbeiten. Steht dort lxc oder openvz, fragen Sie Ihren Anbieter, wann er den Host-Kernel aktualisiert. uname -r zeigt die laufende Kernel-Version, zum Beispiel 6.8.0-147-generic.

Ubuntu-Kernel aktualisieren: Update, Neustart, Prüfung

Auf einem KVM-VPS mit Standard-Kernel genügen diese Befehle:

sudo apt update
sudo apt upgrade
sudo reboot

Nach dem Neustart melden Sie sich wieder an und prüfen die Version:

uname -r
dpkg -l 'linux-image*' | grep ^ii

Diese Versionen des Pakets linux liegen am 7. November 2026 laut Launchpad und packages.ubuntu.com in -updates:

• Ubuntu 22.04 LTS (jammy): Paket 5.15.0-203.213, uname -r zeigt 5.15.0-203-generic
• Ubuntu 24.04 LTS (noble): Paket 6.8.0-149.149, uname -r zeigt 6.8.0-149-generic
• Ubuntu 26.04 LTS (resolute): Paket 7.0.0-43.43, uname -r zeigt 7.0.0-43-generic
• Ubuntu 26.10 (stonking): 7.3.0-10.10, im Tracker bereits als „Fixed“ markiert

Wichtig ist die Zahl nach dem ersten Bindestrich in uname -r. Zeigt Ihr 24.04-Server nach dem Neustart noch 6.8.0-147-generic, läuft der alte Kernel. Dafür gibt es zwei mögliche Ursachen. Entweder hat apt upgrade den neuen Kernel nicht installiert, oder der Server wurde noch nicht neu gestartet. Die Liste aus dpkg -l zeigt die installierten Kernel. Steht 6.8.0-149 in der Liste, während uname -r eine ältere Version meldet, fehlt nur der Neustart. Canonical schreibt ausdrücklich, dass nach der Installation des Kernels ein Neustart nötig ist.

apt upgrade holt den neuen Kernel, obwohl er ein neues Paket ist. Laut der Handbuchseite apt(8) installiert upgrade neue Pakete, wenn Abhängigkeiten sie verlangen. Das Metapaket linux-image-generic hängt am jeweils neuesten Kernel. Deshalb zieht es linux-image-6.8.0-149-generic nach.

Warum automatische Updates hier nichts tun

Die Fix-Versionen liegen in -updates, nicht in -security. Für noble steht in -security am 7. November laut Launchpad noch 6.8.0-147.147. Das ist wichtig, wenn Sie sich auf unattended-upgrades verlassen. In der Ubuntu-Vorlage des Projekts unattended-upgrades ist die Zeile für ${distro_codename}-updates auskommentiert. Prüfen Sie Ihre eigene Datei:

grep -n 'updates' /etc/apt/apt.conf.d/50unattended-upgrades

Beginnt die Zeile mit -updates mit //, ist sie abgeschaltet. Der automatische Dienst holt den Fix dann erst, wenn er auch in -security erscheint. Spielen Sie das Update deshalb jetzt von Hand ein.

Warum der Tracker noch „work in progress“ sagt

Am 7. November führt der Ubuntu CVE Tracker für 24.04 den Status „Vulnerable work in progress in 6.8.0-149.149“. Für 22.04 und 26.04 steht dort derselbe Status mit der jeweiligen Version. Der Tracker nennt also schon die Fix-Version, hat den Status aber noch nicht auf „Fixed“ gesetzt. Canonicals Blogbeitrag vom 2. November nennt genau diese Versionen als Fix. Der Tracker ist einfach langsamer als das Archiv. Vergleichen Sie deshalb uname -r mit den Versionen oben. Öffnen Sie den Tracker-Eintrag erneut, bevor Sie einen Server als erledigt abhaken.

Welche Kernel-Variante läuft bei Ihnen?

Die Liste oben gilt für das Paket linux, also den Standard-Kernel. Ubuntu baut aber viele Varianten. Der Tracker führt jede davon einzeln, und viele sind noch nicht so weit. Am 7. November steht dort zum Beispiel:

• 24.04 mit HWE-Kernel 7.0 (linux-hwe-7.0): „work in progress in 7.0.0-43.43~24.04.1“
• 24.04 mit HWE-Kernel 6.17 (linux-hwe-6.17): „Vulnerable“, ohne Version
• 24.04 mit linux-aws: „work in progress in 6.8.0-1069.74“
• 22.04 mit linux-kvm: „work in progress in 5.15.0-1112.117“
• 22.04 mit HWE-Kernel 6.8 (linux-hwe-6.8): „work in progress in 6.8.0-149.149~22.04.1“

HWE heißt Hardware Enablement: ein neuerer Kernel für ein älteres LTS-Release. GA (General Availability) ist der Kernel, mit dem das Release erschienen ist. Laut dem Kernel-Lifecycle von Ubuntu starten Server-Installationen von 24.04 mit dem GA-Kernel 6.8, und den HWE-Kernel gibt es optional. Den Unterschied erklärt unser Beitrag HWE- oder GA-Kernel auf Ubuntu Server. Ein 24.04-Server mit GA-Kernel bekommt den Fix also schon über 6.8.0-149.149. Ein 24.04-Server mit HWE 7.0 bekommt ihn noch nicht. Das Metapaket linux-image-generic-hwe-24.04 steht in noble-updates noch auf 7.0.0-42.42~24.04.1. Welche Variante bei Ihnen läuft, zeigt dieser Befehl:

dpkg -l 'linux-generic*' 'linux-virtual*' 'linux-image-*' | grep ^ii

Nur den Kernel aus -proposed holen (deb822, Ubuntu 24.04)

-proposed ist der Testkanal für SRUs (Stable Release Updates). Dort landen Pakete, bevor sie nach -updates wandern. Laut Launchpad liegt der HWE-Kernel 7.0 für 24.04 in der Version 7.0.0-43.43~24.04.1 seit dem 5. November in noble-proposed. Wer nicht warten will, kann genau diesen Kernel von dort holen. Alles andere bleibt auf -updates. Bedenken Sie dabei: Laut Canonical wandern Kernel erst nach Tests auf mehr als 2.000 zertifizierten Servern und Geräten nach -updates. Ein Kernel aus -proposed hat diese Tests noch nicht hinter sich.

Ab 24.04 nutzt Ubuntu das deb822-Format mit .sources-Dateien. Die SRU-Anleitung von Ubuntu gibt diesen Eintrag vor:

sudo tee /etc/apt/sources.list.d/proposed.sources > /dev/null <<'SRC'
Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: noble-proposed
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
SRC
sudo apt update

Auf ARM-Servern lautet die URI http://ports.ubuntu.com/ubuntu-ports. Meldet apt update danach doppelte Einträge, hilft die Erklärung zum Fehler mit doppelten deb822-Quellen.

Erst prüfen, welche Priorität apt dem Kanal gibt

Bevor Sie etwas installieren, sehen Sie nach, wie apt den neuen Kanal bewertet:

apt-cache policy | grep -A1 proposed
apt-cache policy linux-generic-hwe-24.04

Die Zahl vor jeder Quelle ist ihre Priorität. Lesen Sie die Zahl für noble-proposed auf Ihrem Server ab, statt sie anzunehmen. Erwarten können Sie 100. Die Release-Datei von noble-proposed setzt NotAutomatic: yes und ButAutomaticUpgrades: yes. Laut apt_preferences(5) bekommen Archive mit diesen beiden Feldern die Priorität 100. Normale Quellen haben 500. Mit 100 liegt -proposed unter den normalen Quellen, also nimmt ein normales apt upgrade die Versionen aus -updates. Die SRU-Anleitung verlangt erst für Releases vor 24.04 eine eigene Pin-Datei. Steht bei Ihnen trotzdem 500, gibt es auf dem Server eine eigene Pin-Regel. Dann würde ein apt upgrade alles Neuere aus -proposed holen. Entfernen Sie in dem Fall den Eintrag, bevor Sie weitermachen.

Die zweite Zeile zeigt, ob -proposed überhaupt eine neuere Version des Metapakets hat. Fehlt dort die Version 7.0.0-43.43~24.04.1, gibt es nichts zu holen. Dann warten Sie, oder Sie setzen die Firewall-Regel weiter unten.

Das Metapaket installieren

sudo apt install -t noble-proposed --only-upgrade linux-generic-hwe-24.04

-t noble-proposed hebt die Priorität des Kanals nur für diesen einen Befehl an. --only-upgrade verhindert, dass apt das Paket neu installiert, wenn es bei Ihnen fehlt. Lesen Sie die Paketliste, bevor Sie bestätigen. Dort sollten nur Kernel-Pakete stehen, also Image, Module und Header. Steht dort etwas anderes, brechen Sie ab. Danach folgen der Neustart und uname -r. Die Ausgabe sollte jetzt 7.0.0-43-generic lauten.

Den Eintrag wieder entfernen

sudo rm /etc/apt/sources.list.d/proposed.sources
sudo apt update
apt-cache policy linux-generic-hwe-24.04

Der installierte Kernel bleibt auf dem Server. Kommt dieselbe Version später nach noble-updates, zeigt apt-cache policy sie dort an. Künftige Kernel bekommt Ihr Server dann wieder auf dem normalen Weg.

Für 22.04 und ältere Releases nutzt die SRU-Anleitung eine einzeilige proposed.list. Dazu kommt eine Pin-Datei /etc/apt/preferences.d/proposed mit Pin-Priority: 100. Folgen Sie dort genau der SRU-Anleitung von Ubuntu.

Zurück zum alten Kernel, wenn der neue Probleme macht

Löschen Sie den alten Kernel erst, wenn der neue ein paar Tage sauber läuft. Wie Sie später aufräumen, steht in alte Kernel unter Ubuntu sicher entfernen.

Startet der Server mit dem neuen Kernel nicht, öffnen Sie die Web-Konsole Ihres Anbieters. SSH hilft hier nicht, denn Sie müssen das Boot-Menü sehen. Laut GRUB-Handbuch zeigt GRUB ein verstecktes Menü an, wenn Sie während der Wartezeit Esc oder F4 drücken oder Shift gedrückt halten. grub-mkconfig legt den Kernel mit der höchsten Version als obersten Eintrag an. Die übrigen Kernel landen in einem Untermenü, das bei Ubuntu „Advanced options for Ubuntu“ heißt. Dort wählen Sie die alte Version, zum Beispiel 6.8.0-147-generic.

Diese Wahl gilt nur für diesen einen Start. Wie Sie einen bestimmten Kernel dauerhaft als Standard setzen, zeigt festlegen, welcher Kernel auf dem VPS startet. Bleibt der Server schon vor dem GRUB-Menü stehen, lesen Sie den Leitfaden für einen VPS, der nach dem Kernel-Update nicht mehr startet. Denken Sie daran: Der alte Kernel hat die Lücke noch. Der Rückweg ist eine Notlösung, und dann gehört die Firewall-Regel unten auf den Server.

Übergangslösung: die nft-Regel gegen IPv4-Optionen

Hat Ihre Kernel-Variante noch keinen Fix, können Sie den Angriffsweg verkleinern. Red Hat veröffentlicht im Bulletin RHSB-2026-016 die folgende Regel. Der Ubuntu-Tracker beschreibt dieselbe Regel mit gleicher Tabelle, gleicher Priorität und gleichem Ausdruck. Sie verwirft eingehende IPv4-TCP-Pakete, die IP-Optionen tragen. ip hdrlength > 5 bedeutet, dass der IPv4-Header länger ist als 20 Byte. Genau 20 Byte hat ein Header ohne Optionen.

Legen Sie die Datei /etc/cve-2026-98432.nft an. Diesen Pfad nennt der Ubuntu-Tracker.

sudo tee /etc/cve-2026-98432.nft > /dev/null <<'NFT'
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
NFT
sudo nft --check --file /etc/cve-2026-98432.nft
sudo nft --file /etc/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

nft --check meldet einen Fehler, wenn die Datei falsch ist, und lädt dabei nichts. Der letzte Befehl listet die Tabelle mit ihrem Zähler. Steigt counter packets später an, hat die Regel tatsächlich Pakete verworfen.

Die Grenzen dieser Regel stehen im Tracker selbst. Sie gehören zu jeder Entscheidung über die Regel:

• Die Regel „reduces the risk but does not fully prevent exploitation“. Sie senkt also das Risiko, verhindert den Angriff aber nicht sicher.
• Sie unterbricht TCP-Verbindungen, die IPv4-Optionen brauchen. Verbindungen ohne IP-Optionen laufen normal weiter. TCP-Optionen wie Timestamps sind etwas anderes und bleiben unberührt.
• Sie schützt den Host, auch Verbindungen vom Host zu sich selbst. Container sind nicht automatisch dabei: „Containers with separate networking need the rule applied separately.“ Ein Container mit eigenem Netzwerk-Namespace braucht die Regel also noch einmal in sich selbst.

Red Hat schreibt außerdem, dass die Regel einen Neustart nicht übersteht. Der Ubuntu-Tracker empfiehlt dafür eine include-Zeile in /etc/nftables.conf und den Dienst nftables. Schauen Sie vorher in diese Datei. Beginnt sie mit flush ruleset, löscht sie beim Laden alle anderen Regeln, auch die von ufw oder Docker. Auf so einem Server laden Sie die Regel nach jedem Neustart lieber von Hand mit sudo nft --file /etc/cve-2026-98432.nft, bis der Kernel-Fix installiert ist.

Nach dem Kernel-Update entfernen Sie die Regel wieder:

sudo nft delete table inet cve_2026_98432

Wie sich die Regel mit ufw verträgt

Die Regel steht in einer eigenen Tabelle und ändert keine Regel von ufw. Laut nftables-Wiki arbeitet Netfilter die Ketten eines Hooks in aufsteigender Priorität ab. Mit -310 läuft diese Kette also sehr früh. Ein drop dort ist endgültig, auch wenn ufw den Port später erlauben würde. Umgekehrt öffnet policy accept nichts, was ufw sperrt, denn das Paket durchläuft danach weiter die Ketten von ufw. Testen Sie das trotzdem auf Ihrem Server. Vergleichen Sie sudo ufw status vorher und nachher, und öffnen Sie eine neue SSH-Sitzung, bevor Sie die alte schließen. Wie die beiden Werkzeuge unter Ubuntu zusammenhängen, erklärt iptables und nftables unter Ubuntu.

Hilft es, MPTCP abzuschalten?

Hier unterscheiden sich die Quellen. Red Hat führt sysctl -w net.mptcp.enabled=0 auf, weil einige Organisationen das empfohlen haben. Red Hat schreibt aber gleich dazu: Der Schalter blockiert nur einen Weg der Ausnutzung und ist keine vollständige Abhilfe. Er wirkt nur auf neue Sockets, laufende Dienste müssten also neu starten. Red Hat empfiehlt deshalb die Paketfilter-Regel statt des Schalters.

Canonical geht weiter. Im Blogbeitrag vom 2. November schreibt das Ubuntu-Sicherheitsteam, der Fix sei „not specific to MPTCP“. Der Rat, MPTCP (Multipath TCP) abzuschalten, stützt sich laut Canonical nur darauf, dass der bekannte Exploit MPTCP benutzt. Für Canonical sind Sicherheitsupdates die einzige angemessene Abhilfe. Ein Server ohne MPTCP-Dienst ist deshalb nicht automatisch sicher. Wer net.mptcp.enabled trotzdem auf 0 setzt, schließt damit nur einen bekannten Weg. Den aktuellen Wert auf Ihrem Server zeigt sysctl net.mptcp.enabled.

Deckt Livepatch diese Lücke ab?

Stand 7. November 2026 haben wir keinen Livepatch-Hinweis (LSN, Livepatch Security Notice) für CVE-2026-98432 gefunden. Der neueste LSN, den wir öffnen konnten, ist LSN-0122-1 vom 7. Oktober. Er erschien vor der Veröffentlichung der Lücke und nennt sie nicht. LSN-0123-1 liefert einen 404. Canonicals Blogbeitrag zur Lücke erwähnt Livepatch nicht.

Die Lücke passt zu den Kriterien von Livepatch. Livepatch zielt auf Kernel-Fehler, die mit hoch oder kritisch eingestuft sind und zum Beispiel Remote Code Execution erlauben. Passen heißt aber nicht abgedeckt. Canonical selbst schreibt, Livepatch „is not a replacement for updating the kernel package and then rebooting“. Prüfen Sie den Stand auf Ihrem Server:

canonical-livepatch status

Solange kein LSN mit dieser CVE-Nummer existiert, gilt Ihr Server als ungeschützt. Kernel-Update und Neustart bleiben der Fix. Wie Livepatch auf einem VPS grundsätzlich arbeitet, steht in Live-Kernel-Patching auf einem VPS.

Wer hat die Lücke gefunden?

In vielen Berichten steht, „ein Anthropic-Forscher“ habe den Fehler entdeckt. Anthropics eigener Beitrag vom 27. Oktober 2026 trägt den Titel „Discovering and exploiting vulnerabilities in critical, real-world software with Claude“. Er beschreibt ein unveröffentlichtes, internes Forschungsmodell. Der Abschnitt über Remote Code Execution unter Linux nennt CVE-2026-98432. Dort steht, Claude habe einen Exploit für Linux-Server mit einem Multipath-TCP-Listener geschrieben. Eine einzelne Person als Finder nennt der Beitrag nicht. Canonical bezeichnet den Exploit als noch unveröffentlicht und schreibt, dass kein anderer Exploit bekannt ist.

Was gilt für Debian und RHEL?

Die Aussage „in Debian und RHEL schon behoben“ stimmt für RHEL am 7. November nicht. Das Red-Hat-Bulletin RHSB-2026-016 wurde zuletzt am 4. November aktualisiert. Es nennt RHEL 8, 9 und 10 als betroffen, listet aber keine fertigen Errata und keine Kernel-Versionen. Red Hat schreibt, es beschleunige die Fixes. Den Stand bei Debian haben wir nicht in einer Primärquelle geprüft. Sehen Sie dafür selbst im Debian Security Tracker nach.

FAQ

Muss ich nach dem Kernel-Update für CVE-2026-98432 neu starten?

Ja. Das Update legt den neuen Kernel nur auf die Platte, und der alte läuft weiter, bis Sie neu starten. Prüfen Sie danach mit uname -r. Auf Ubuntu 24.04 mit Standard-Kernel muss dort 6.8.0-149-generic oder neuer stehen, auf 22.04 5.15.0-203-generic und auf 26.04 7.0.0-43-generic.

Warum zeigt der Ubuntu CVE Tracker noch „Vulnerable“, obwohl das Update da ist?

Am 7. November 2026 führt der Tracker für 22.04, 24.04 und 26.04 den Status „Vulnerable work in progress“, gefolgt von der Fix-Version. Laut Launchpad und packages.ubuntu.com liegen die Pakete aber schon in -updates. Der Tracker ist langsamer als das Archiv. Vergleichen Sie Ihre Version aus uname -r mit der Fix-Version, die der Tracker nennt.

Bin ich auf einem Container-VPS geschützt, wenn ich apt upgrade ausführe?

Nein. Ein LXC- oder OpenVZ-Container nutzt den Kernel des Hosts, also hängt der Fix am Anbieter. systemd-detect-virt zeigt Ihnen die Art der Virtualisierung. Bei kvm aktualisieren Sie selbst. Bei lxc oder openvz fragen Sie den Anbieter nach dem Stand des Host-Kernels.

Reicht die nft-Regel gegen IPv4-Optionen als Schutz?

Nein. Laut Ubuntu-Tracker senkt sie das Risiko, verhindert die Ausnutzung aber nicht sicher. Sie unterbricht Verbindungen, die IPv4-Optionen brauchen. Laut Red Hat übersteht sie keinen Neustart. In Containern mit eigenem Netzwerk muss sie separat gesetzt werden. Sie überbrückt nur die Zeit bis zum Kernel-Fix.

Schützt mich Canonical Livepatch vor CVE-2026-98432?

Stand 7. November 2026 hat Canonical keinen Livepatch-Hinweis für diese CVE veröffentlicht. canonical-livepatch status zeigt, was auf Ihrem Server aktiv ist. Bis ein Hinweis mit dieser CVE-Nummer erscheint, sind Kernel-Update und Neustart der einzige belegte Fix.