Drei alte Linux-Kernel-Fehler wurden in die CISA-KEV-Liste aufgenommen

Die Kurzfassung

Zur Langfassung springen ↓

Worum es geht: Am 18. September 2026 hat die CISA drei Sicherheitslücken im Linux-Kernel in ihren Katalog „Known Exploited Vulnerabilities“ aufgenommen. CVE-2025-39682 betrifft den TLS-Empfangspfad des Kernels, CVE-2026-53266 betrifft das ebtables-SNAT-Ziel, das bei Netzwerkbrücken verwendet wird, und CVE-2025-39964 ist ein Race-Condition-Problem bei AF_ALG-Krypto-Sockets. Drei voneinander unabhängige Subsysteme, drei verschiedene Expositionstests. Zu diesem Abschnitt springen →

Auswirkungen: Diese variieren weitaus stärker, als die Schlagzeilen vermuten lassen. Der kTLS-Fehler führt dazu, dass spätere Datensätze unter falschen Annahmen bezüglich Zero-Copy und Warteschlangen verarbeitet werden. Der ebtables-Fehler kann dazu führen, dass ein Kernel-Schreibvorgang in einer dateibasierten Seite landet, die über diesen Pfad eigentlich gar nicht verändert werden sollte. Red Hat beschreibt dies als einen Weg zu Speicherbeschädigungen, Denial-of-Service-Angriffen oder der Ausnutzung von Sicherheitslücken. Der AF_ALG-Race-Condition führt für sich genommen zu einem lokalen Absturz oder einer beschädigten Krypto-Ausgabe, doch öffentlicher Exploit-Code nutzt ihn nun aus, um auf einem betroffenen Kernel eine Root-Shell zu erlangen. Zu diesem Abschnitt springen →

Schweregrad: Differenzierter als in den Schlagzeilen dargestellt. Red Hat bewertet sie mit 7, 0, 7, 5 und 7,3 und stuft sie entsprechend als „mäßig“, „wichtig“ und „mäßig“ ein, da die Schweregradskala mehr als nur den reinen Zahlenwert widerspiegelt. NVD und die Linux CNA verwenden für einige dieser Schwachstellen unterschiedliche Bewertungskriterien, woraus sich die höheren Werte von 9,8, 8,8 und 7,8 ergeben. Zu diesem Abschnitt springen →

Wer ist betroffen: RHEL und dessen Derivate, darunter AlmaLinux, Rocky Linux, Oracle Linux und CloudLinux, wobei der Umfang je nach CVE variiert. Für CVE-2025-39682 gibt Red Hat an, dass nur EL9 und EL10 betroffen sind. Die beiden anderen CVEs haben einen größeren Geltungsbereich, und CVE-2026-53266 listet nun sogar RHEL 6 im Rahmen des erweiterten Supports auf. Jeder Fehler weist zudem eine Vorbedingung auf, die das tatsächliche Risiko verringert. Zu diesem Abschnitt springen →

Status: Keine Zero-Day-Schwachstellen. Alle Upstream-Korrekturen wurden bereits vor der Veröffentlichung dieser Liste vorgenommen; die Korrekturen für kTLS und AF_ALG liegen mehr als ein Jahr zurück. In den Aufzeichnungen von Red Hat werden die drei Schwachstellen nun als bekannte Exploits gekennzeichnet, doch weder die CISA noch Red Hat haben über den mit KEV verknüpften Status hinaus eine Angriffskette, Angriffsziele oder Telemetriedaten veröffentlicht, und die Nutzung durch Ransomware wird als unbekannt angegeben. Für zwei der drei Schwachstellen gibt es mittlerweile auch öffentlichen Exploit-Code. Zu diesem Abschnitt springen →

Gehen Sie wie folgt vor: Installieren Sie einen festen Hersteller-Kernel und starten Sie das System damit neu, oder lassen Sie KernelCare die Live-Patches ohne Neustart anwenden, sofern diese für den aktuell ausgeführten Kernel verfügbar sind. Und lassen Sie die Blacklist für das af_alg-Modul weg. Bei den hier geprüften Enterprise-Linux-Kerneln ist AF_ALG bereits integriert, sodass die Blacklist keine Wirkung hat. Zu diesem Abschnitt springen →

Bevor Sie sich auf eine af_alg-Umgehungslösung verlassen, sollten Sie überprüfen, wie AF_ALG in den laufenden Kernel integriert ist:

grep -E 'CONFIG_CRYPTO_USER_API' /boot/config-(uname-r)2>/dev/null||grep-E'CONFIGCRYPTOUSERAPI'/lib/modules/(uname -r)/config

Falls CONFIG_CRYPTO_USER_API=y erscheint in der Ausgabe, AF_ALG ist eingebunden und Keine Modul-Blacklist kann diese Funktion deaktivieren.

Dass drei Kernel-CVEs am selben Tag in KEV landen, klingt wie ein einziges Ereignis. Tatsächlich handelt es sich jedoch um drei separate Vorfälle, bei denen es weder eine gemeinsame Fehlerklasse noch ein gemeinsames Subsystem gibt und bei denen es keinen einzigen Test gibt, mit dem sich feststellen lässt, ob ein Host gefährdet ist.

Gemeinsam war ihnen jedoch der Zeitpunkt und der damit verbundene Wirbel. Die Veröffentlichung ging mit einer dreitägigen Frist zur Behebung der Schwachstellen für zivile Bundesbehörden gemäß BOD 26-04 einher, und in den darauf folgenden Berichten wurde ein Schweregrad von 9,8 genannt und behauptet, Red Hat habe unabhängig bestätigt, dass alle drei Schwachstellen aktiv ausgenutzt würden. In den Aufzeichnungen von Red Hat werden die CVEs zwar als bekannte Exploits gekennzeichnet, doch dieser Status bezieht sich auf die KEV-Auflistung und nicht auf veröffentlichte Telemetriedaten von Red Hat; zudem muss der Wert von 9,8 im Kontext betrachtet werden, da er aus einer anderen Bewertungsskala stammt als der, die Red Hat für RHEL verwendet.

Auch keiner der Fehler ist neu. Der kTLS-Fix wurde am 19. August 2025 im Upstream-Kernel integriert, der AF_ALG-Fix am 16. September 2025 und der ebtables-Fix am 23. Mai 2026. Es handelt sich also um ein „N-Day“-Patching-Problem, und die entscheidende Frage für jeden Host lautet, ob der Fix jemals den tatsächlich laufenden Kernel erreicht hat.

Die CISA hat alle drei CVEs am 18. September in den KEV-Katalog aufgenommen und für zivile Bundesbehörden eine Frist zur Behebung gemäß BOD 26-04 bis zum 21. September festgelegt. Drei Tage sind nach KEV-Maßstäben eine kurze Frist.

Die Aufnahme bedeutet, dass die CISA über Beweise für eine Ausnutzung verfügt, die sie als zuverlässig erachtet. Das bedeutet nicht, dass diese Beweise öffentlich sind – und das sind sie hier auch nicht. Die Katalogeinträge enthalten keine technischen Details, die begleitende Warnmeldung macht keine Angaben zu Angriffsketten oder Zielen, und bei allen drei Einträgen wird die Verwendung im Rahmen bekannter Ransomware-Kampagnen als „Unbekannt“ angegeben.

Die Datensätze von Red Hat enthalten nun für alle drei eine Kennzeichnung für bekannte Exploits, doch Red Hat hat keine eigenen Details zu den Exploits, Angriffsketten, Zielen oder Telemetriedaten veröffentlicht, und die Kennzeichnung orientiert sich an der KEV-Liste und nicht an unabhängigen Beobachtungen von Red Hat. Betrachten Sie sie als dasselbe Signal, das auch KEV liefert, und nicht als zweite Quelle.

Betrachten Sie die Auflistung daher als glaubwürdigen Hinweis darauf, dass die CISA über Hinweise verfügt, dass diese Schwachstellen ausgenutzt werden, und wägen Sie dann jede einzelne Schwachstelle anhand ihrer tatsächlichen Voraussetzungen ab. Die Einstufung als „KEV“ erhöht zwar die Priorität, doch die praktische Dringlichkeit hängt weiterhin davon ab, ob der jeweilige anfällige Pfad auf dem Host erreichbar ist.

Die im Umlauf befindlichen Werte 9,8, 8,8 und 7,8 sind korrekt, und die produktspezifischen Bewertungen von Red Hat weichen wiederum davon ab: 7,0 für CVE-2025-39682, 7,5 für CVE-2026-53266 und 7,3 für CVE-2025-39964. Die Unterschiede ergeben sich aus unterschiedlichen Angriffsvektoren und Annahmen hinsichtlich der Ausnutzbarkeit und der Auswirkungen.

CVE-2025-39682 ist ein gutes Beispiel dafür. Das NVD bewertet ihn mit 9,8, während Red Hat für RHEL einen Wert von 7,0 vergibt. Beide stufen ihn als über das Netzwerk erreichbar ein, doch Red Hat weist ihm eine hohe Angriffskomplexität sowie geringere Auswirkungen auf Vertraulichkeit und Integrität zu, sodass derselbe Fehler in einer ganz anderen Kategorie landet.

Diese Unterscheidung ist für die Analyse von Bedeutung, sollte jedoch kein Grund sein, die Behebung der Sicherheitslücke aufzuschieben. Alle drei sind im KEV-Katalog der CISA aufgeführt, und die entscheidende Frage ist nicht, welche Bewertung höher ist. Prüfen Sie, ob der anfällige Pfad auf Ihren Systemen erreichbar ist, legen Sie anhand dessen Prioritäten fest, wenden Sie den korrigierten Kernel oder den Live-Patch an und vergewissern Sie sich, dass der laufende Kernel tatsächlich abgedeckt ist.

CVE-2025-39682 betrifft die Empfangsseite von Kernel-TLS, die kernelinternen Record-Ebene, die es Anwendungen ermöglicht, einen Teil der TLS-Record-Verarbeitung nach dem Handshake an den Kernel auszulagern.

Jedes recvmsg() Der Aufruf soll entweder eine Folge zusammenhängender Datensätze oder einen einzelnen Nicht-Datensatz verarbeiten, niemals eine Mischung aus beidem. Ein Datensatz mit der Länge Null, der bereits in der Warteschlange steht, rx_list Dies umgeht die Typüberprüfung für Datensätze, sodass die nachfolgenden Datensätze unter falschen Annahmen hinsichtlich Zero-Copy und Warteschlangenverarbeitung behandelt werden. Diese Diskrepanz untergräbt die Annahmen des Empfangspfads bezüglich der Datensätze und der von ihm verwalteten Puffer, weshalb Red Hat diesen Fehler als schwerwiegender einstuft als einen einfachen Verfügbarkeitsfehler.

Die Erreichbarkeit ist das Entscheidende. Zu haben CONFIG_TLS im Kernel reicht nicht aus. Das TLS-Protokoll der oberen Schicht muss an einen TCP-Socket angehängt werden, was nur dann geschieht, wenn dies ausdrücklich aktiviert wurde – beispielsweise bei einer Nginx-Installation, die für die Verwendung von kTLS konfiguriert ist, bei einer Anwendung, die auf einem kompatiblen OpenSSL-kTLS-Pfad basiert, oder bei NFS über TLS über tlshd. Wenn kTLS bewusst aktiviert ist und die Anwendung die Deaktivierung unterstützt, führt die Deaktivierung der Auslagerung dazu, dass die Verarbeitung der Datensätze wieder in den Userspace verlagert wird, was mit einem gewissen CPU-Aufwand verbunden ist. Betrachten Sie dies als vorübergehende Abhilfemaßnahme und nicht als Ersatz für das Aufspielen eines Patches.

Die Korrektur ist im Upstream-Commit enthalten 62708b9452f8, vom 19. August 2025. Red Hat hat am 29. September 2025 korrigierte RHEL 9- und RHEL 10-Kernel ausgeliefert; die 9.2-SAP- und 9.4-EUS-Streams folgten Ende Oktober. Für diese CVE stuft Red Hat RHEL 6, 7 und 8 als „nicht betroffen“ ein. Der anfällige Code wurde upstream in Linux 6.0 eingeführt und ist in den RHEL-9- und RHEL-10-Kernel-Streams vorhanden, jedoch nicht in den auf 4.18 basierenden Versionen von RHEL 8 oder früheren Versionen. Inzwischen ist öffentlicher Exploit-Code aufgetaucht, der diese Schwachstelle ausnutzt, um eine Kernel-Speicherbeschädigung und eine Root-Shell gegen ein spezifisches kernelCTF-Ziel zu erzielen. Dies ist zwar nicht mit einem portablen Exploit für RHEL-Kernel in der Produktion gleichzusetzen, bedeutet jedoch, dass der „Receive-Path“-Fehler an irgendeiner Stelle als Angriffsmittel genutzt wurde.

Der Ebtables-SNAT-Fehler, der in die falsche Seite schreibt

CVE-2026-53266 weist mit 7,5 den höchsten Red Hat CVSS-Wert der drei auf, wird von Red Hat als „Wichtig“ eingestuft und weist den interessantesten Fehlermodus auf.

Das SNAT-Ziel von ebtables kann optional die Hardware-Adresse des Absenders in ARP-Paketen umschreiben, wenn diese eine Bridge passieren. Dies geschieht durch skb_store_bits(), das in die nichtlinearen Fragmente des Pakets schreibt. Eines dieser Fragmente kann durch eine Dateiseite gestützt werden, die über splice, sodass der Schreibvorgang auf einer dateibasierten Seite landen kann, die über diesen Pfad eigentlich gar nicht verändert werden sollte. Red Hat ordnet dies dem CWE-825 zu und beschreibt das Ergebnis als einen Weg zu Speicherbeschädigungen, Denial-of-Service-Angriffen oder einer Ausweitung von Berechtigungen.

Die Voraussetzung ist streng. Es muss eine vom Administrator konfigurierte ebtables-SNAT-Regel mit ARP-Rewrite auf einer Bridge vorhanden sein, und ein Angreifer kann eine solche Regel nicht aktivieren. Viele Hosts in einer Bridge nutzen ebtables-NAT überhaupt nicht. Überprüfen Sie als erste schnelle Maßnahme die NAT-Tabelle auf eine SNAT-Regel mit ARP-Rewrite:

sudo ebtables -t nat -L | grep -i 'snat-arp'

Betrachten Sie dies eher als eine erste Konfigurationsprüfung denn als endgültigen Beweis in die eine oder andere Richtung. Das Fehlen einer Übereinstimmung ist ein deutlicher Hinweis darauf, dass die Regel auf diesem Host nicht konfiguriert ist. Bei einer Übereinstimmung sollte der Host – vorbehaltlich Ihres eigenen Änderungsprozesses – an den Anfang der Behebungswarteschlange rücken. Falls die Umschreibung tatsächlich nicht erforderlich ist, kann das Deaktivieren dieser spezifischen Regel das Risiko verringern, bis der korrigierte Kernel verfügbar ist; überprüfen Sie die Änderung jedoch vor der Umsetzung anhand des Netzwerkdesigns.

Der Upstream-Fix ist der Commit 67ba971ae025, vom 23. Mai 2026. Red Hat hatte die Sicherheitslücken in RHEL 8 und 9 bereits im Juli, also lange vor der Veröffentlichung der Liste, behoben und folgte am 24. September mit RHEL 10 und RHEL 7 ELS sowie am 30. September mit RHEL 6 ELS. RHEL 9 kernel-rt wird weiterhin als betroffen gekennzeichnet.

Zwei Schreibvorgänge an einem AF_ALG-Socket

CVE-2025-39964 ist ein Parallelitätsfehler in AF_ALG, der Socket-Schnittstelle, die die Krypto-API des Kernels für den Userspace bereitstellt. Zwei gleichzeitig ausgeführte Schreibvorgänge auf denselben AF_ALG-Socket können sich überschneiden und zu einer Inkonsistenz im Kontext des jeweiligen Sockets führen.

Red Hat beschreibt die direkte Sicherheitslücke so, dass ein lokaler Benutzer das System zum Absturz bringen oder kryptografische Ergebnisse verfälschen kann. Bei der Bewertung gehen die Meinungen auseinander. Die Primärbewertung des NVD liegt bei 5,5 und bezieht sich ausschließlich auf Auswirkungen auf die Verfügbarkeit. Die Linux CNA bewertet die Schwachstelle mit 7,8, während Red Hat eine Bewertung von 7,3 vergibt, wobei dieser Wert Auswirkungen auf Vertraulichkeit und Integrität berücksichtigt. Ausschlaggebend ist der öffentlich bekannte Exploit. Ein Repository nutzt die Race-Condition aus, um eine Speicherbeschädigung im Kernel zu verursachen, eine Kernel-Adresse preiszugeben und Daten zu überschreiben. core_pattern, und erhält Root-Rechte. Sowohl die Notizen des Autors als auch eine unabhängige Überprüfung weisen auf fest codierte Offsets und eine KASLR-Umgehung hin, die möglicherweise nicht auf alle Kernel übertragbar ist. Es handelt sich also um eine nachgewiesene Kette zur Rechteausweitung auf einer gezielt angepassten Version und nicht um einen portablen Exploit gegen unterstützte RHEL-Versionen. So oder so gilt die Einschätzung, dass es sich lediglich um einen Absturz handelt, nicht mehr, und auf gemeinsam genutzten oder Multi-Tenant-Hosts spielt dies eine Rolle.

Der Upstream-Fix ist der Commit 1b34cbbf4f01, datiert vom 16. September 2025. Dies ist auch die CVE, für die Red Hat nach der Veröffentlichung am schnellsten Korrekturen bereitgestellt hat. Am 21. September gab es bei Red Hat noch keine Errata dazu für irgendein Produkt. Die ersten Errata erschienen am 22. September, und bis zum 24. September waren Korrekturen für RHEL 8, 9, 10 und RHEL 7 ELS sowie für die Varianten mit erweitertem Support bereitgestellt worden.

Die AF_ALG-Umgehungslösung, die nichts bewirkt

Das hier wird den Leuten noch ganz schön zusetzen.

In früheren Empfehlungen von Red Hat zu CVE-2025-39964 wurde empfohlen, die af_alg das Laden des Moduls. Die aktuelle Seite enthält diese Zeile nicht mehr, und das ist auch gut so, denn sie hat auf den hier getesteten Enterprise-Linux-Kerneln nie funktioniert. AF_ALG ist dort fest in den Kernel integriert und wird nicht als ladbares Modul ausgeliefert. Die mitgelieferten Kernel von AlmaLinux 8, 9 und 10 sowie CloudLinux 8 legen fest, dass CONFIG_CRYPTO_USER_API=y, wobei die AF_ALG-Implementierung und ihre Frontends bereits integriert sind. Die modules.builtin Dateilisten kernel/crypto/af_alg.ko, und das Paket enthält keine separate af_alg.ko.

A modprobe.d Die Blacklist kann daher ohne Fehler akzeptiert werden, kann jedoch keine integrierte Komponente deaktivieren. Das Gleiche gilt für modprobe.blacklist=af_alg in der Kernel-Befehlszeile. In den getesteten Konfigurationen wurde kein unterstützter sysctl- oder Boot-Parameter gefunden, der AF_ALG deaktiviert.

Und die Überprüfung, auf die die meisten Menschen zurückgreifen, geht genau in die falsche Richtung:

lsmod | grep af_alg

Eine leere Ausgabe bedeutet nicht, dass AF_ALG inaktiv ist. Bei den hier überprüften Kerneln entspricht dies der Tatsache, dass AF_ALG fest eingebaut ist und nicht als Modul geladen wird, was Sie mit dem Befehl CONFIG_CRYPTO_USER_API „grep“ aus dem Anfang dieses Beitrags und mit modules.builtin. Ein Host sollte nicht allein deshalb als geschützt betrachtet werden, weil dieser Befehl keine Ergebnisse liefert. Wenn die Konfiguration Folgendes anzeigt: =y, die tatsächlichen Optionen sind ein gepatchter Kernel oder ein Patch ohne Neustart. Als mehrschichtige Verteidigung kann eine sorgfältig getestete Seccomp-Richtlinie den Zugriff verweigern socket() erfordert für bestimmte Workloads die Adressfamilie AF_ALG, doch dies ist worklastspezifisch und bietet keinen Schutz vor gewöhnlichen lokalen Benutzern auf dem Host.

Hier sehen Sie, wie sich die drei wichtigsten Enterprise-Linux-Familien in den bis zum 2. Oktober 2026 ausgewerteten Quellen darstellten. In jeder Zelle wird zunächst der Kernel-Status des Anbieters angegeben; bei AlmaLinux und CloudLinux wird zusätzlich die „KernelCare“-Abdeckung ohne Neustart aufgeführt, sofern diese abweicht, da es sich bei den beiden um unterschiedliche Arten von Korrekturen handelt. Achten Sie bitte eher auf die Bezeichnungen als nur auf die Datumsangaben:

Rocky Linux und Oracle Linux sind oben nicht gesondert aufgeführt, basieren jedoch auf demselben Upstream-Code wie RHEL. Überprüfen Sie daher die jeweiligen Sicherheitshinweise und den genau verwendeten Kernel, anstatt davon auszugehen, dass die Daten übereinstimmen. Die Extended Update Support (EUS)-Streams von Red Hat für RHEL 8 (8.4, 8.6, 8.8) und RHEL 9 (9.2, 9.4, 9.6) erhielten ebenfalls zwischen dem 23. und 24. September Korrekturen, während die älteren Hauptversionen, RHEL 6 und 7, über den „Extended Life Cycle Support“ (ELS) betreut werden – darauf beziehen sich die ELS-Hinweise in der Tabelle.

Zwei kleinere Anmerkungen. Unter CloudLinux 8 werden Kernel von 4.18.0-553.142.1 In den neueren Versionen ist der Fix für CVE-2026-53266 bereits integriert, also überprüfen Sie uname -r bevor man von einer Sicherheitslücke ausgeht. Und Red Hat hat den Status von RHEL 6 für CVE-2026-53266 Ende September von „Nicht betroffen“ auf „Betroffen“ geändert und am 30. September einen RHEL 6 ELS-Patch veröffentlicht, was für alle wichtig ist, die noch RHEL 6 oder CloudLinux 6 im Rahmen des Extended Life Cycle Support nutzen.

Debian, Ubuntu und Amazon Linux verfolgen diese CVEs nach ihren eigenen Zeitplänen. Informieren Sie sich in der Sicherheitsmitteilung für Ihren jeweiligen Kernel, anstatt sich auf die Angaben für RHEL zu stützen.

Die Patches von KernelCare, die einen Neustart überflüssig machen, decken auch die RHEL-Varianten ab – wie aus der Zeitleiste im Statusfeld oben in diesem Beitrag hervorgeht. Die obige RHEL-Zeile bezieht sich also auf die Kernel von Red Hat selbst und nicht auf das Fehlen einer Option für Patches, die keinen Neustart erfordern.

Holen Sie sich KernelCare noch heute →

Ein auf der Festplatte gespeichertes korrigiertes Kernel-Paket ändert den Kernel im Arbeitsspeicher nicht. Bei einem herkömmlichen Update installieren Sie die korrigierten Kernel-Pakete für genau Ihre Version, starten Sie den Rechner neu und überprüfen Sie, was tatsächlich läuft:

uname -r

Vergleichen Sie dies mit den Empfehlungen von Red Hat oder den Rebuild-Hinweisen, nicht mit dem, was gerade auf der Festplatte als neueste Version vorliegt. Ein Host, auf dem das Update vor drei Wochen installiert wurde und der seitdem nicht neu gestartet wurde, läuft weiterhin mit dem alten Kernel.

Sobald ein unterstützter Patch verfügbar ist, wendet KernelCare die entsprechenden Korrekturen ohne Neustart auf den aktiven Kernel an. Diese Korrekturen werden als „rebootless Live-Patches“ über die zuvor aufgeführten Streams bereitgestellt, wobei die Verfügbarkeit der Live-Patches kernelspezifisch bleibt. Konfigurationen, bei denen automatische Updates aktiviert sind, laden regelmäßig neue Patches herunter, und kcarectl --update fordert eine auf Abruf an. Überprüfen Sie, welche der drei im laufenden Kernel unterstützt werden:

kcarectl --patch-info | grep -E 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

Falls für den aktuell laufenden Kernel kein CVE angezeigt wird, sollten Sie nicht davon ausgehen, dass die Sicherheitslücke durch eine andere Distribution, einen anderen Minor-Zweig oder ein Paket-Update abgedeckt ist, das noch nie zum Systemstart verwendet wurde, und alle validierten vorläufigen Abhilfemaßnahmen beibehalten, bis ein CVE vorliegt. CloudLinux 8 stellt einen Sonderfall dar, da ein aktueller Kernel möglicherweise bereits nativ den Fix für CVE-2026-53266 enthält, auch wenn eine Live-Patch-Abfrage keinen separaten Patch anzeigt.

Nein. Alle Korrekturen waren bereits vor der Veröffentlichung öffentlich zugänglich, und Red Hat hatte bereits fast ein Jahr zuvor Korrekturen für CVE-2025-39682 bereitgestellt. Neu ist lediglich die KEV-Einstufung durch die CISA, die darauf hinweist, dass die Schwachstellen bekanntermaßen ausgenutzt werden, jedoch keine öffentlichen Details zur Ausnutzung liefert. Das ist eine bekannte „N-Day“-Geschichte. Alte Kernel-Korrekturen, die nie angewendet wurden, sind genau das, wonach Angreifer suchen.

Was den Exploit-Code angeht, sollte man jedoch genau sein. Es gibt mittlerweile öffentliche Repositories mit funktionierenden PoCs zur Rechteausweitung für CVE-2025-39682 und CVE-2025-39964, die beide für spezifische Ziele im KernelCTF-Stil mit fest codierten Offsets erstellt wurden. Das ist echte Waffenfähigkeit, kein portabler Exploit gegen eine gepatchte, aber noch nicht neu gestartete Produktionsumgebung; daher ist die Aussage „Es gibt keinen öffentlichen PoC“ zum jetzigen Zeitpunkt schlichtweg falsch, auch wenn die Behauptung „Jeder kann jeden Host rooten“ ebenso falsch ist.

Warum das KEV-Kernel-Trio so wichtig ist

Keiner der drei verfügt über einen breit angelegten, vorraussetzungsfreien Angriffsweg. Bei einem ist kTLS erforderlich, bei einem anderen eine bestimmte, vom Administrator konfigurierte ebtables-Regel, und beim dritten ist lokaler Zugriff erforderlich, obwohl öffentlich zugängliche Exploits mittlerweile eine Kette zur Rechteausweitung gegen einen gezielt angegriffenen Kernel zeigen. Das ist die beruhigende Seite der Medaille.

Die Lehre daraus lässt sich aus allem um sie herum ziehen. Alle drei Probleme waren behebbar, noch bevor die CISA sich dazu äußerte, und Upstream-Korrekturen, Backports der Anbieter, die Bereitstellung in der Flotte und die Ausnutzung der Schwachstellen erfolgen nicht nach demselben Zeitplan. Unterdessen vermittelten die im Umlauf befindlichen Bewertungen den Menschen ein falsches Gefühl der Dringlichkeit, und eine frühere Hersteller-Notlösung für eine CVE hatte stillschweigend keinerlei Wirkung auf die Kernel, die sie eigentlich schützen sollte. Die dreitägige Frist verstrich zudem, bevor Red Hat etwas für CVE-2025-39964 ausgeliefert hatte, sodass der Hersteller-Kernel einfach nicht verfügbar war, als der von der Bundesregierung festgelegte Abhilfetermin für diese Schwachstelle ablief.

Bei Flotten mit herkömmlichen Patches sollten Sie die korrigierten Kernel installieren und nach einem sinnvollen Zeitplan einen Neustart durchführen, wobei Hosts mit ebtables-ARP-Rewrite und kTLS-Hosts an erster Stelle stehen sollten. Bei Flotten, bei denen die Koordination der Neustarts den Engpass darstellt, schließt KernelCare die betroffenen Pfade im laufenden Kernel, während die normale Wartung weiterläuft.

Holen Sie sich KernelCare noch heute →

Zeitleiste

Referenzen

Als Hauptquellen für diesen Beitrag dienen der CISA-Katalog „Known Exploited Vulnerabilities“ (Katalogversion 2026.10.01), die CISA-Warnmeldung vom 18. September 2026, die verbindliche Betriebsrichtlinie 26-04 sowie die CVE-Seiten von Red Hat zu CVE-2025-39682, CVE-2026-53266 und CVE-2025-39964, die NVD-Einträge zu CVE-2025-39682, CVE-2026-53266 und CVE-2025-39964 sowie die Upstream-Korrekturen 62708b9452f8, 67ba971ae025 und 1b34cbbf4f01.