
CVE-2026-98432: TCP-Schwachstelle im Linux-Kernel — was sie bedeutet und was Sie auf Ihrem VPS oder dedizierten Server tun sollten
Eine Lücke im Linux-Kernel kann es einem entfernten Angreifer theoretisch ermöglichen, einen Server während des TCP-Handshakes zum Absturz zu bringen. Wir erklären, wer betroffen ist, welche Distributionen zum 29. Oktober 2026 bereits einen Patch haben und mit welchen konkreten Schritten Sie Ihren VPS oder dedizierten Server schützen.
Zum 29. Oktober 2026 ist die Linux-Kernel-Schwachstelle CVE-2026-98432 in den offiziellen Stable-Zweigen und in Debian behoben, aber Ubuntu, Red Hat, AlmaLinux, Rocky und SUSE 15 haben noch keinen korrigierten Kernel veröffentlicht. Zum Zeitpunkt der Veröffentlichung ist kein öffentlicher Exploit bekannt. Wenn Sie bei Fusiora einen Linux-VPS oder einen dedizierten Linux-Server haben, verwalten Sie den Kernel selbst: Dieser Artikel erklärt, was passiert ist und welche Schritte Sie unternehmen sollten.
Was ist passiert? Einfach erklärt
Wenn jemand eine TCP-Verbindung zu Ihrem Server aufbaut, speichert der Kernel vorübergehend einige Informationen aus dem ersten Paket (dem SYN). Enthält dieses Paket IPv4-Optionen (optionale Felder im IP-Header wie Record Route oder Timestamp, die normaler Datenverkehr fast nie verwendet), kann der Kernel diesen Speicher freigeben, während ein anderer Teil des Systems ihn noch benutzt. Man spricht von einem Use-after-free.
In der Praxis ist das wahrscheinlichste Ergebnis, dass der Server abstürzt und neu startet (Denial of Service). Die offiziellen Quellen sind sich über den Schweregrad uneinig: Der CVE-Eintrag nennt außerdem eine mögliche Offenlegung von Kernel-Speicherinhalten an den Angreifer sowie Speicherkorruption, während Red Hat einen Absturz für am wahrscheinlichsten hält und angibt, dass keine Auswirkung auf Vertraulichkeit oder Integrität nachgewiesen wurde.
Technische Details in Kürze
- Korrektur: Commit
e3f33b0a1d89„ipv4: free inet_opt and ireq_opt after an RCU grace period“ (Eric Dumazet, 1. Oktober 2026), enthalten in Linux 7.3. Er ersetzt zweikfree()-Aufrufe durchkfree_rcu()innet/ipv4/af_inet.cundnet/ipv4/tcp_ipv4.c. - Ursache:
tcp_v4_syn_recv_sock()übergibt die IP-Optionen der Anfrage an den Child-Socket, ohne sie zu kopieren. Trifft gleichzeitig ein wiederholt gesendetes SYN ein, kann eine andere CPU gerade ein SYN-ACK mit diesen Optionen senden, während der Child-Socket zerstört wird und sie freigibt. - Zweite Variante: nur bei aktivierter Migration von TCP-Anfragen (
net.ipv4.tcp_migrate_req=1, standardmäßig 0, oder ein reuseport-BPF-Programm, das Anfragen migriert). - Angriffsvektor: entfernt und ohne Authentifizierung, während des Handshakes, bevor die Anwendung beteiligt ist. Voraussetzung sind ein TCP-Dienst, der auf IPv4 lauscht, ein SYN mit IP-Optionen und eine gewonnene Race Condition. Der CNA stuft die Komplexität als niedrig ein, Red Hat und SUSE als hoch.
- IPv6: von der Hauptlücke nicht betroffen. IPv6 muss nicht deaktiviert werden.
Wer ist betroffen?
- Linux-VPS: Jeder VPS bootet seinen eigenen Kernel, den Sie über das Betriebssystem installieren und aktualisieren. Läuft auf Ihrem VPS ein verwundbarer Kernel, müssen Sie ihn aktualisieren und neu starten.
- Dedizierte Linux-Server: ebenso. Sie haben vollen Root-Zugriff und der Kernel liegt in Ihrer Verantwortung.
- Container (Docker, LXC, Podman) auf Ihrem Server: Sie teilen sich den Kernel des Hosts und sind daher geschützt, sobald der Kernel dieses Servers aktualisiert ist.
- Nicht betroffen: Windows Server und FreeBSD, da sie nicht den Linux-Kernel verwenden.
Wichtig. Dieser Artikel behandelt das Betriebssystem, das Sie selbst verwalten. Wenn Sie Fragen zu einem anderen Teil Ihres Dienstes haben, eröffnen Sie ein Ticket und wir melden uns bei Ihnen.
Patch-Stand zum 29. Oktober 2026
Offizielle Kernel (kernel.org). Diese Versionen oder jede spätere Version desselben Zweigs enthalten die Korrektur bereits:
Der CVE-Eintrag nennt keinen korrigierten 4.x- oder 5.4-Zweig (beide werden offiziell nicht mehr unterstützt).
Nach Distribution. Beachten Sie, dass Distributionen ihre Kernel nach eigenem Schema nummerieren; entscheidend ist daher das jeweils korrigierte Paket:
Bei Distributionen, die aktuelle Kernel aus den offiziellen Zweigen ausliefern (zum Beispiel Fedora, Arch oder Alpine), vergleichen Sie Ihre Version mit der kernel.org-Tabelle. Wenn Sie Debian 10 oder 11 oder ein anderes nicht mehr unterstütztes System verwenden, rechnen Sie nicht mit einem Patch: Planen Sie den Umstieg auf eine unterstützte Version (auf einem VPS im Panel unter Manage → Rebuild; beachten Sie, dass eine Neuinstallation alle Daten löscht; bei einem dedizierten Server eröffnen Sie ein Ticket). CentOS 7 verwendet den Kernel von RHEL 7, der laut Red Hat von dieser CVE nicht betroffen ist, erhält aber keine Sicherheitsupdates mehr: Eine Migration ist trotzdem ratsam.
Schritte für Kunden
Verbinden Sie sich per SSH (Anleitung) und führen Sie die Befehle als root oder mit sudo aus.
1. Prüfen, welcher Kernel läuft
uname -r
Unter Debian steht die genaue Paketversion am Ende der Ausgabe von:
uname -v
Zum Beispiel bedeutet „Debian 6.12.113-1“ oder höher unter Debian 13, dass Sie die korrigierte Version bereits haben. Unter Ubuntu, RHEL und deren Derivaten ist die Nummer von uname -r die eigene Nummerierung der Distribution: Vergleichen Sie sie mit deren Advisory, nicht mit der kernel.org-Tabelle.
2. Vor jeder Änderung ein Backup erstellen
Wenn Ihr Tarif Snapshots umfasst, erstellen Sie vor dem Update einen. Andernfalls kopieren Sie alles, was Sie nicht verlieren dürfen, vom Server herunter. Ein Kernel-Update ist Routine, aber beim Neustart kann ein bereits bestehendes Problem zutage treten.
3. Das System aktualisieren
Debian und Ubuntu:
apt update && apt full-upgrade
Wenn Sie unter Debian 12 den 6.12-Kernel aus dem Paket linux-6.12 (DLA-4850-1) verwenden, aktualisiert full-upgrade auch diesen. So prüfen Sie die installierten Kernel-Pakete:
dpkg -l 'linux-image*'
AlmaLinux, Rocky, RHEL, Fedora, Oracle und CloudLinux:
dnf upgrade --refresh
rpm -q kernel
SUSE und openSUSE:
zypper refresh && zypper patch
Arch:
pacman -Syu
Alpine:
apk update && apk upgrade
Für Ubuntu, RHEL, AlmaLinux und Rocky gibt es zum 29. Oktober noch keinen korrigierten Kernel; für Oracle Linux (UEK-Kernel) und CloudLinux prüfen Sie das Advisory Ihres Anbieters. Es lohnt sich trotzdem, ausstehende Updates einzuspielen, und Sie sollten diesen Schritt wiederholen, sobald Ihre Distribution ihr Advisory veröffentlicht (siehe Schritt 8); wenden Sie in der Zwischenzeit die Abhilfe aus Schritt 5 an.
4. Neu starten und die neue Version prüfen
Der neue Kernel wird erst nach einem Neustart verwendet:
reboot
Sobald der Server wieder erreichbar ist, führen Sie erneut uname -r aus (und unter Debian uname -v) und vergleichen das Ergebnis mit dem korrigierten Paket Ihrer Distribution (Tabelle „Nach Distribution“) oder mit der kernel.org-Tabelle, wenn Sie einen offiziellen Kernel verwenden. Wenn der Server nach dem Neustart nicht per SSH antwortet:
- VPS: Melden Sie sich im Panel vps.fusiora.com an und öffnen Sie die VNC-Konsole (Reiter Options → Browser VNC; wenn Sie die Schaltfläche nicht sehen, klicken Sie zuerst auf Enable VNC).
- Dedizierter Server: Verwenden Sie die IPMI/KVM-Fernkonsole.
- Im GRUB-Menü (unter Debian und Ubuntu unter „Advanced options“; erscheint das Menü nicht, halten Sie beim Booten Shift gedrückt oder drücken Sie Esc) können Sie den vorherigen Kernel wählen, während Sie den Fehler untersuchen.
5. Wenn Ihre Distribution noch keinen Patch hat: vorübergehende Abhilfe
Die Lücke wird nur durch IPv4-TCP-SYNs mit IP-Optionen ausgelöst, die im legitimen Datenverkehr sehr selten sind. Sie können diese Pakete mit nftables verwerfen. Die Regel lässt normale SYNs durch und betrifft weder IPv6 noch andere Protokolle. Wenn Ihr Server Datenverkehr weiterleitet (zum Beispiel als Router oder VPN-Gateway), filtert sie diese SYNs auch im Transit. Sie ersetzt den Patch nicht.
Wenn der Befehl nft fehlt, installieren Sie ihn mit apt install nftables oder dnf install nftables. Die Regel liegt in einer eigenen Tabelle, die neben ufw, firewalld und Docker existieren kann:
nft add table inet cve_2026_98432
nft add chain inet cve_2026_98432 pre '{ type filter hook prerouting priority -300; policy accept; }'
nft add rule inet cve_2026_98432 pre 'ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop'
Zur Kontrolle (der Zähler zeigt, wie viele Pakete verworfen wurden):
nft list table inet cve_2026_98432
Zum Entfernen:
nft delete table inet cve_2026_98432
Auf diese Weise hinzugefügt, übersteht die Regel keinen Neustart. Tragen Sie sie dafür nicht in /etc/nftables.conf ein und aktivieren Sie dafür nicht nftables.service: Je nach Distribution leert diese Konfiguration alle Regeln des Systems, auch die von Docker oder ufw. Wenn die Regel Neustarts überdauern soll, speichern Sie sie in einer eigenen Datei, /etc/cve-2026-98432.nft:
table inet cve_2026_98432 {
chain pre {
type filter hook prerouting priority -300; policy accept;
ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop
}
}
Und laden Sie sie mit einem eigenen Dienst, /etc/systemd/system/cve-2026-98432.service:
[Unit]
Description=Mitigation CVE-2026-98432
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table inet cve_2026_98432
[Install]
WantedBy=multi-user.target
Entfernen Sie zuerst die manuelle Regel, falls Sie sie hinzugefügt haben (nft delete table inet cve_2026_98432), damit sie nicht doppelt vorhanden ist. Dann:
systemctl daemon-reload && systemctl enable --now cve-2026-98432.service
Sobald Sie den korrigierten Kernel verwenden, schalten Sie sie mit systemctl disable --now cve-2026-98432.service ab.
Auf älteren Systemen ohne nftables lautet das iptables-Äquivalent:
iptables -t raw -I PREROUTING -p tcp --syn -m u32 ! --u32 "0>>22&0x3C=20" -j DROP
Wie die von Hand hinzugefügte nft-Regel übersteht auch diese keinen Neustart.
Prüfen Sie außerdem, dass die Migrationsvariante deaktiviert ist (die Ausgabe sollte 0 sein, der Standardwert):
sysctl net.ipv4.tcp_migrate_req
Meldet der Befehl, dass der Schlüssel nicht existiert, fehlt Ihrem Kernel diese Funktion und die Variante trifft nicht zu.
Filtern Sie nicht alle Pakete mit IP-Optionen: IGMP verwendet sie, und Sie würden Multicast lahmlegen. Die obige Regel ist bewusst auf TCP-SYNs beschränkt.
6. Livepatch: nur dort, wo es ihn gibt
Zum 29. Oktober 2026 haben wir weder bei Canonical noch bei Red Hat oder SUSE einen Livepatch für diese CVE gefunden. SUSE hat für 16.0 einen korrigierten Kernel veröffentlicht (6.12.0-160000.40.1), der einen Neustart erfordert. Ohne Livepatch besteht die Lösung darin, den Kernel zu aktualisieren und neu zu starten.
7. Prüfen, was Sie ins Internet öffnen
Die Lücke setzt einen TCP-Dienst voraus, der auf IPv4 lauscht. Jetzt ist ein guter Zeitpunkt, in Ihrer Firewall (ufw oder firewalld) nicht benötigte Ports zu schließen und Administrationsports auf Ihre eigenen IPs zu beschränken. Unsere Anleitung Ihren ersten VPS einrichten beschreibt die grundlegende Firewall-Konfiguration.
8. Advisories verfolgen und bei Bedarf Hilfe anfordern
Verfolgen Sie die CVE-Seite Ihrer Distribution (Links unten) und wiederholen Sie die Schritte 3 und 4, sobald der korrigierte Kernel erscheint. Wenn Sie Fragen haben oder nach dem Update etwas nicht startet, eröffnen Sie ein Ticket mit Ihrem Dienst und der Ausgabe von uname -r.
Häufige Fragen
Aktualisiert Fusiora den Kernel auf meinem VPS oder dedizierten Server?
Nein, es sei denn, Sie haben einen Managed-Service gebucht; in diesem Fall wenden Sie sich an den Support. Bei einem Standard-VPS oder dedizierten Server haben Sie vollen Root-Zugriff und verwalten das Betriebssystem selbst, einschließlich des Kernels. Wenn Sie Hilfe bei den Schritten möchten, eröffnen Sie ein Ticket.
Reicht es, die Pakete zu aktualisieren?
Nein. Bis zum Neustart läuft weiterhin der alte Kernel. Prüfen Sie mit uname -r, dass die neue Version aktiv ist.
Muss ich IPv6 deaktivieren?
Nein. IPv6 ist von der Hauptlücke nicht betroffen.
Kann die nftables-Regel etwas kaputt machen?
Sie verwirft nur IPv4-TCP-SYNs mit IP-Optionen, die im legitimen Datenverkehr sehr selten sind. IPv6 und andere Protokolle bleiben unberührt, und ein einziger Befehl entfernt sie.
Ist mein Windows Server betroffen?
Nein. Es handelt sich um eine Schwachstelle im Linux-Kernel.
Wird die Lücke bereits ausgenutzt?
Zum Zeitpunkt der Veröffentlichung ist kein öffentlicher Exploit bekannt, und die CVE steht nicht im KEV-Katalog der CISA. Wir aktualisieren diesen Artikel, falls sich das ändert.
Quellen
- CVE.org: offizieller Eintrag des Linux-CNA, veröffentlicht am 2026-10-15 und aktualisiert am 2026-10-24
- NVD: CVE-Eintrag mit der Bewertung des CNA (geprüft am 2026-10-29)
- Ubuntu: Status je Release, Priorität High (aktualisiert am 2026-10-28)
- Debian Security Tracker: korrigierte Pakete, DSA-6568-1, DLA-4841-1 und DLA-4850-1 (geprüft am 2026-10-29)
- Red Hat: Einstufung Moderate und Status „Fix deferred“ (geprüft am 2026-10-29)
- SUSE: Status je Produkt (geprüft am 2026-10-29)
- Linux-Korrektur-Commit: „ipv4: free inet_opt and ireq_opt after an RCU grace period“ (2026-10-01)
- kernel.org: aktuelle Stable-Versionen (geprüft am 2026-10-29)
- CISA KEV: Katalog ausgenutzter Schwachstellen, ohne diese CVE (geprüft am 2026-10-29)
War dieser Artikel hilfreich?
Sei der Erste, der bewertet