Eine kritische TCP-Sicherheitslücke im Linux-Kernel kann die Ausführung von Code aus der Ferne ermöglichen (CVE-2026-98432)

TL;DR

CVE-2026-98432 ist eine Schwachstelle in der Art und Weise, wie der Linux-Kernel IPv4-TCP-Verbindungen aufbaut; sie ist in Kernel-Versionen ab 4.4 vorhanden. Das kerneleigene CVE-Team bewertet die Schwachstelle mit 9,8 von 10 Punkten. Anthropic berichtet, dass ein noch nicht veröffentlichtes Claude-Forschungsmodell einen Exploit geschrieben hat, der einem Angreifer aus der Ferne Root-Rechte auf einem Linux-Server mit einem Multipath-TCP-Listener (MPTCP) verschafft – ohne Anmeldedaten und ohne Benutzerinteraktion. AWS bestätigt, dass unter bestimmten Bedingungen ein nicht authentifizierter Angreifer aus der Ferne Code ausführen könnte. Bis zum 2. November hatte noch kein Anbieter oder CERT Angriffe in freier Wildbahn gemeldet, und die CVE war nicht im Katalog der bekannten ausgenutzten Schwachstellen der CISA aufgeführt. Der Forscher Marcus Hutchins hat inzwischen berichtet, dass offenbar Angreifer das Internet nach MPTCP-fähigen Servern absuchen.

So beheben Sie CVE-2026-98432

Installieren Sie einen gepatchten Kernel und starten Sie das System neu. AWS bezeichnet dies als die einzige vollständige Abhilfe und gibt an, dass auch ein Live-Patch das Problem behebt.

Ermitteln Sie zunächst alle betroffenen VMs. Berücksichtigen Sie dabei auch vergessene Hosts und die Knoten unter Ihren Containern. Die Funktion „Virtual Machines“ unterAikidokennzeichnet diejenigen, auf denen ein betroffener Kernel läuft.

Amazon Linux. Für Amazon Linux 2 und 2023 stehen gepatchte Kernel-Pakete für die Kernel-Versionen 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 und 6.18 zur Verfügung.

• Amazon Linux 2: sudo yum update kernel && sudo reboot
• Amazon Linux 2023: sudo dnf update kernel --releasever=latest && sudo reboot

Kubernetes, ECS und andere verwaltete AWS-Dienste

• EKS: Aktualisieren Sie verwaltete Knotengruppen, selbstverwaltete Knoten und Karpenter-Knoten auf die AMI-Version v20261031 oder höher. Der EKS-Auto-Modus ersetzt die Knoten automatisch.
• ECS auf EC2: Aktualisieren Sie den Kernel und starten Sie das System neu oder ersetzen Sie die Instanzen durch solche mit der ECS-optimierten AMI-Version 20261031.
• Fargate: Neue Aufgaben, die nach dem 1. November 2026, 6:00 Uhr PDT, gestartet werden, nutzen die aktualisierte Plattform. Bestehende Aufgaben werden gemäß Ihren Einstellungen zur Aufgabenstilllegung stillgelegt, oder Sie können sie bereits früher ersetzen.
• Bottlerocket: Die aktualisierten AMIs wurden ab dem 2. November erwartet.

Andere Distributionen. Informieren Sie sich im Tracker Ihres Anbieters, da sich der Status täglich ändert.

• Ubuntu: 26.10 ist in 7.3.0-10.10 behoben. Korrekturen für 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149) und 26.04 (7.0.0-43.43) befinden sich im Test-Repository „-proposed“, aus dem apt standardmäßig keine Pakete installiert. Daher müssen Sie dieses Repository aktivieren und den Kernel explizit mithilfe der Befehle aus dem Beitrag von Canonical installieren. Für 16.04, 18.04 und 20.04 wird weiterhin ein ausstehender Fix angezeigt, und Cloud-, FIPS- sowie Echtzeit-Kernel haben ihre eigenen Versionen auf der CVE-Seite von Ubuntu.
• Red Hat: Am 1. November wurden korrigierte Kernel für RHEL 8 (RHSA-2026:93414), RHEL 9 (RHSA-2026:93412) und RHEL 10 (RHSA-2026:93413) bereitgestellt, zusammen mit weiteren Sicherheitshinweisen für die EUS-, SAP- und NVIDIA-Streams. Stand 3. November waren RHEL 9 kernel-rt sowie die OpenShift 4- und 5-CoreOS-Images weiterhin als betroffen aufgeführt; RHEL 6 und 7 sind nicht betroffen.
• Debian, Oracle Linux und SUSE: Laut The Hacker News wurden für zumindest einige Kernel korrigierte Pakete bereitgestellt.

Einen eigenen Kernel erstellen. Der Upstream-Fix ist in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3 enthalten. Das Kernel-CVE-Team empfiehlt, auf den neuesten stabilen Kernel umzusteigen, anstatt den Patch einzeln zu übernehmen.

Wie „ Aikido “ hilft

AikidoDie Überprüfung der virtuellen Maschinen erkennt CVE-2026-98432 auf Ihren verbundenen VMs mit einem Basis-Schweregrad von 9,8. Aikido passt den Schweregrad pro VM basierend auf der Netzwerkreichweite an. Nutzen Sie daher die Ansicht „Erreichbarkeit“, um zu sehen, welche VMs über das Internet erreichbar sind, und patchen Sie diese zuerst.

Falls Sie Ihre VMs noch nicht verbunden haben, gehen Sie unter Aikido auf „Virtual Machines“ und wählen Sie „Connect VMs“ aus. „ Aikido “ unterstützt AWS, Azure und GCP.

Die Erkennung erfolgt auf Grundlage von Herstellerhinweisen. Falls ein Hersteller noch kein Kernel-Update veröffentlicht hat, kann ein Host anfällig sein, ohne als betroffen angezeigt zu werden. Überprüfen Sie daher auch den Tracker Ihrer Distribution. Ein Host, auf dem das Update installiert, aber noch kein Neustart durchgeführt wurde, kann als behoben angezeigt werden. Führen Sie daher zunächst einen Neustart durch.

​

Falls du das Update noch nicht installieren kannst

Diese Schritte verringern das Sicherheitsrisiko. Keiner davon behebt den Fehler, daher sollten Sie einen Patch installieren und das System neu starten, sobald Ihr Anbieter einen neuen Kernel bereitstellt. AWS führt die ersten beiden Maßnahmen als vorläufige Abhilfemaßnahmen auf, während Red Hat angibt, dass keine der von ihm geprüften Abhilfemaßnahmen einfach zu implementieren, für die meisten Installationen geeignet und stabil ist. Wenn Sie einen Go-Server betreiben, der nicht hinter einem Load Balancer läuft, verwenden Sie die unten angegebene Go-Einstellung.

1. Deaktivieren Sie MPTCP. Setzen Sie „net.mptcp.enabled=0“. Für Programme mit Go 1.24 oder höher setzen Sie „GODEBUG=multipathtcp=0“. Dies ist wichtig, da der Exploit von Anthropic einen MPTCP-Listener benötigte und Go 1.24 und höher diese standardmäßig anfordern, sofern der Kernel MPTCP zulässt. Es handelt sich um eine schwache Schutzmaßnahme: Das Go-Sicherheitsteam bezeichnet die Deaktivierung auf Programmebene als unzuverlässig, da bereits ein einziger offener MPTCP-Listener das System weiterhin angreifbar macht. Laut Marcus Hutchins bleiben durch die Einstellung „net.mptcp.enabled=0“ bereits geöffnete MPTCP-Sockets bestehen; daher sollten betroffene Dienste anschließend neu gestartet werden. Um MPTCP-Listener aufzulisten, führen Sie „sudo ss -Mlnp“ aus.
2. IPv4-Pakete, die IP-Optionen enthalten, werden verworfen. AWS gibt folgende Regel an: iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. Dies ist von Bedeutung, da die Schwachstelle darin besteht, wie der Kernel die bei einer ausstehenden Verbindung gespeicherten IP-Optionen verarbeitet, und der Angriff ein SYN-Paket nutzt, das diese Optionen enthält. Für die AWS Network Firewall veröffentlicht AWS eine entsprechende zustandsorientierte Regel, bei der die Reihenfolge der Regeln strikt eingehalten werden muss.
3. Stellen Sie den Host hinter einen separaten Load Balancer oder Managed Service, der die TCP-Verbindung beendet, bevor der Datenverkehr Ihren Kernel erreicht. Ein Proxy auf demselben Host zählt nicht. Aktualisieren Sie die dahinter liegenden Instanzen trotzdem.

So überprüfen Sie, ob der Fix bereits live ist

Ein Kernel-Update wird erst nach einem Neustart wirksam. Überprüfen Sie daher den aktuell ausgeführten Kernel und nicht den installierten.

uname -r

Vergleichen Sie die Ausgabe mit der korrigierten Kernel-Version, die in der Sicherheitsmitteilung Ihres Anbieters angegeben ist. Anbieter portieren Korrekturen zurück, verwenden Sie daher deren eigene korrigierte Version und nicht die des Upstream-Projekts. Wenn weiterhin die alte Version angezeigt wird, wurde der Host noch nicht mit dem gepatchten Kernel neu gestartet.

Wiederholen Sie diesen Vorgang auf jeder VM, einschließlich der vergessenen und der Knoten unter Ihren Containern.

Wer ist betroffen

Jeder Linux-Host mit Kernel 4.4 oder höher, der über einen IPv4-TCP-Port verfügt, auf den ein Angreifer zugreifen kann. IPv6 ist von der Hauptschwachstelle nicht betroffen. Bei AWS umfasst dies selbstverwaltete EC2- und Lightsail-Instanzen, ECS auf EC2- container -Instanzen sowie EKS-Knoten. AWS Lambda ist nicht betroffen, da Funktionen keine öffentlichen IPv4-TCP-Ports offenlegen.

Was vor dem Moderator steht, beeinflusst die Belichtung:

• AWS WAF, Application Load Balancer, Classic Load Balancer, TLS-Listener des Network Load Balancers, CloudFront und API Gateway. AWS gibt an, dass diese Dienste bei Einhaltung der Best Practices keine TCP-Verbindungen aus nicht vertrauenswürdigen Quellen direkt an Ihre Instanzen weiterleiten und dass die zugrunde liegende Infrastruktur derzeit gepatcht wird. Es wird weiterhin empfohlen, die dahinter liegenden Instanzen innerhalb von 30 Tagen zu aktualisieren.
• TCP-Listener des Network Load Balancer und Global Accelerator. AWS empfiehlt seinen Kunden, ihre Plattformversion zu aktualisieren, sobald gepatchte Versionen verfügbar sind.
• Ein Proxy wie nginx oder HAProxy auf Ihrem eigenen Linux-Host. Dies ist kein Schutzschild. Der Kernel des Rechners, der die Verbindung annimmt, wickelt den TCP-Handshake ab, daher benötigt auch der Proxy-Host den Patch.

Bei Containern ist der Kernel entscheidend, der auf dem Knoten läuft, auf dem die Container ausgeführt werden.

Wie ernst ist die Lage?

Behandeln Sie dies bei jedem Host mit Internetanbindung als dringlich. Drei Punkte sind dabei besonders hervorzuheben:

• Ein Exploit für den Root-Zugriff aus der Ferne wurde demonstriert. Das „Frontier Red Team“ von Anthropic berichtet, dass Claude nach einer ersten Aufforderung einen Exploit geschrieben habe, der Befehle als Root auf einem Linux-Server mit einem Multipath-TCP-Listener (MPTCP) ausführt. In ihrem Test dauerte es 48 Minuten, bis eine Kernel-Adresse offengelegt wurde, und weitere 5 Minuten, bis die Befehlsausführung erreicht wurde.
• Der Angreifer kann es erneut versuchen. Laut Anthropic führt ein fehlgeschlagener Handshake lediglich dazu, dass dieser eine Handshake fehlschlägt, ohne das System zum Absturz zu bringen, sodass ein entschlossener Angreifer so lange weiter versuchen kann, bis es funktioniert.
• Diese Voraussetzung ist möglicherweise häufiger anzutreffen, als es zunächst den Anschein hat. Eine Anwendung muss MPTCP anfordern, wenn sie eine „ socket “ öffnet, und laut dem Go Security Team tun Go-Programme dies seit Go 1.24 standardmäßig für die Sockets, auf denen sie im Listen-Modus laufen. Der Kernel muss MPTCP zudem zulassen, und bei einigen Distributionen, wie beispielsweise AlmaLinux und CloudLinux, ist diese Funktion standardmäßig deaktiviert. Ist sie aktiviert, kann ein Go-Server im Listen-Modus laufen, ohne dass jemand dies ausdrücklich ausgewählt hat.

Einige Fragen bleiben offen. Anthropic hat weder den Exploit noch die Kernel-Version oder die getestete Konfiguration veröffentlicht, und das Kernel-Team von CloudLinux gibt an, die Behauptung nicht reproduzieren zu können. Die Schwachstelle befindet sich im regulären IPv4-TCP-Code, und weder im CVE-Eintrag noch im Kernel-Patch wird MPTCP erwähnt, sodass laut dem Go Security Team Systeme ohne MPTCP-Listener möglicherweise für ähnliche Angriffe anfällig sind. In dem Bulletin von Red Hat heißt es, dass MPTCP keine notwendige Voraussetzung für diese Schwachstelle ist und dass OpenShift-Knoten in ihrer Standardkonfiguration, bei der MPTCP deaktiviert ist, weiterhin betroffen sind. Bis zum 2. November hatte kein Anbieter und kein CERT Angriffe in freier Wildbahn gemeldet. Marcus Hutchins berichtet, dass private Proxys und in Russland ansässige VPN-Server am 2. November begonnen haben, Port 443 über MPTCP abzufragen, was seiner Vermutung nach ein Scan nach dieser CVE ist; bei seinem eigenen Scan am 30. Oktober fand er etwa 2,1 Millionen Server, die über MPTCP auf diesem Port erreichbar waren.

Die meisten Anbieter bewerten es schlechter als das Kernel-Team, da sie die Chancen auf einen Sieg als geringer einschätzen:

‍Was ist CVE-2026-98432?

Einfach ausgedrückt: Der Kernel kann einen Speicherbereich freigeben, während eine andere CPU diesen noch ausliest. Ein Angreifer, der den Zeitpunkt kontrollieren kann, kann dies laut dem CVE-Team des Kernels ausnutzen, um Kernel-Speicher auszulesen oder zu manipulieren oder das System zum Absturz zu bringen.

Während eines TCP-Handshakes sendet der Client ein SYN-Paket, woraufhin der Server mit einem SYNACK antwortet. Der Kernel behält die IP-Optionen aus dem SYN-Paket mit einem Platzhalter für die halboffene Verbindung bei, der als „Request- socket “ bezeichnet wird. In der Funktion `tcp_v4_syn_recv_sock()` übernimmt der neue Kind- socket -Prozess diese Optionen, ohne sie zu kopieren. Wenn eine andere CPU noch dabei ist, ein SYNACK für ein erneut gesendetes SYN-Paket zu erstellen, können die Optionen freigegeben werden, während sie noch in Gebrauch sind. Dies ist ein „Use-after-free“-Fehler, der hier in der Funktion `ip_options_build()` auftritt.

Die Anforderung einer „ socket “-Migration (net.ipv4.tcp_migrate_req=1 oder ein BPF-Programm „reuseport migrate“) eröffnet einen ähnlichen Weg. Die Upstream-Korrektur ersetzt die „frees“-Aufrufe durch „kfree_rcu()“, das so lange wartet, bis keine CPU mehr auf den Speicher zugreifen kann. IPv6 umgeht das erste Problem, da der Kernel die Optionen für IPv6-Verbindungen kopiert. Ein ähnliches Migrationsproblem besteht auch für IPv6, es tritt jedoch nur dort auf, wo CALIPSO IPv6-Optionen setzt, und der Kernel behebt es in einem separaten Patch.

Der Fehler trat erstmals in Linux 4.4 auf. Die Kernel-Entwickler haben den Fehler am 5. Oktober behoben, und die CVE-Kennung wurde am 15. Oktober veröffentlicht. In den Credits zur Kernel-Korrektur wird ein Forscher von Anthropic als Melder des Fehlers genannt.

​