Drei ausgenutzte Linux-Kernel-Lücken im KEV-Katalog der CISA

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastruktursicherheit für Enterprise-Teams in den USA und der EU

Die kurze Antwort

Was die CISA gemeldet hat

Am 18. September 2026 nahm die US-Behörde für Cyber- und Infrastruktursicherheit (CISA) drei Linux-Kernel-Schwachstellen in ihren Katalog bekannter ausgenutzter Schwachstellen (KEV) auf und verwies auf Belege für eine Ausnutzung in freier Wildbahn. Gemäß Binding Operational Directive 26-04 müssen zivile Bundesbehörden alle drei bis zum 21. September beheben — und, ungewöhnlich, hat die CISA jede einzelne als triage-pflichtig markiert: Behörden müssen betroffene Systeme aktiv auf Anzeichen einer Kompromittierung untersuchen und dürfen das Einspielen des Patches nicht als Abschluss der Arbeit betrachten.

Am schwerwiegendsten ist CVE-2025-39682 mit CVSS 9.8. Es handelt sich um eine unzureichende Prüfung eines Ausnahmezustands im Empfangspfad von Kernel TLS (kTLS): ein Sonderfall, in dem ein aus der internen rx_list abgerufener Datensatz mit Länge null die vorgesehene Datensatztyp-Behandlung in recvmsg() umgeht, was zu Speicheroffenlegung oder Denial of Service führt. Das Advisory von Red Hat stuft das Problem als hochriskant ein und stellt fest, dass bereits öffentliche Exploits existieren. CVE-2026-53266 (CVSS 8.8) ist ein Out-of-bounds-Write im Source-NAT-Pfad der netfilter-Bridge (ebtables), ausgelöst bei ARP-Sender-Hardwareadress-Rewrite-Operationen, der unerwartetes Verhalten, einen Absturz oder lokale Rechteausweitung verursachen kann. CVE-2025-39964 (CVSS 7.8) ist eine Race-Condition, die gleichzeitige Schreibvorgänge auf denselben AF_ALG-Socket — die Krypto-aus-Userspace-Schnittstelle des Kernels — erlaubt und das System zum Absturz bringen oder das Ergebnis einer kryptografischen Operation beschädigen kann, was sowohl ein Verfügbarkeits- als auch ein Datenintegritätsrisiko schafft.

Die drei stehen nicht miteinander in Zusammenhang, und es gibt keine Hinweise auf eine einzelne koordinierte Angriffskette; es sind drei voneinander unabhängige Kernel-Schwächen, die zufällig am selben Tag einen KEV-Eintrag erhielten. Die Distributionen reagierten schnell — Red Hat etwa aktualisierte seine Advisories am 19. September — und die Behebung ist bei allen drei dieselbe: den korrigierten Kernel der Distribution installieren und neu starten oder, wo unterstützt, einen Live-Patch anwenden.

Warum „lokal“ nicht „geringes Risiko“ bedeutet

Zwei dieser Lücken benötigen lokalen Zugriff, und die dritte betrifft lokal authentifizierte Nutzer — was beruhigend klingen kann, bis man sich daran erinnert, was „lokal“ in einer cloud-nativen Umgebung bedeutet. Ein Container, aus dem ein Angreifer ausgebrochen ist, ein aus einem Web-App-Exploit gewonnener Brückenkopf, eine kompromittierte Abhängigkeit in einem CI-Job oder ein Dienstkonto mit geringen Rechten sind alle „lokal“. In der Praxis ist der Erst-Einbruch selten das Ziel; die Eskalation von diesem Brückenkopf zu Root auf dem Host ist es. Der Out-of-bounds-Write von CVE-2026-53266 ist genau diese Art von Rechteausweitungs-Primitiv, und die Fähigkeit von CVE-2025-39964, kryptografische Ergebnisse zu beschädigen, untergräbt die Integritätsgarantien, auf die andere Kontrollen bauen.

Die kTLS-Lücke wirft eine andere Frage auf. Kernel TLS verlagert die Verschlüsselung von Netzwerkströmen aus Performance-Gründen in den Kernel und wird von Diensten und Proxys mit hohem Durchsatz genutzt. Ein aus der Ferne erreichbarer Pfad, der in Speicheroffenlegung oder einem Absturz dieses Subsystems endet, ist die Art von Primitiv, die Angreifer in größere Kampagnen einbinden — was wahrscheinlich die 9.8 und den Hinweis auf existierende öffentliche Exploits erklärt. Die bei Kernel-CVEs wiederkehrende Lehre: Schweregrad bemisst sich daran, was ein Angreifer von dort erreichen kann, wo er bereits ist — und in mandantenfähiger Infrastruktur ist „bereits in einem Container auf einem geteilten Knoten“ ein häufiger Ausgangspunkt, kein entfernter.

Was das für Software-Teams im DACH-Raum bedeutet

Erstens: Ein Kernel-CVE ist ein Flotten-Ereignis, kein Server-Ereignis. Der Kernel ist die einzige Komponente, die Ihre VMs, Container und CI-Runner alle teilen — die Gefährdung skaliert also mit Ihrer Infrastruktur, nicht mit einer einzelnen Anwendung. Das verändert die Form der Behebung: Sie patchen keinen Dienst, Sie rollen Kernel über jeden Host und Knoten aus, bauen die Container-Basis-Images neu, die den Kernel über den Host erben, und starten neu oder patchen live, ohne Produktionslast zu verlieren. Teams, deren Cloud- und DevOps-Plattform Kernel-Updates bereits als automatisierte, getestete Pipeline behandelt, fangen das an einem Tag ab; Teams, die Kernel von Hand patchen, entdecken, wie viele Hosts sie vergessen hatten.

Zweitens: Die Drei-Tage-Uhr ist ein Test für Inventar und Orchestrierung, nicht für guten Willen. Wenn die CISA einem KEV-Eintrag forensische Triage anhängt, reicht Patchen allein ausdrücklich nicht — Sie müssen sagen können, welche Hosts betroffen waren, wann sie gepatcht wurden und ob einer davon vorher berührt wurde. Das verlangt aktuelle Asset-Daten, zentrales Logging und die Fähigkeit, kurzfristig einen außerplanmäßigen Neustart über die Umgebung zu planen. Solche Fähigkeiten baut man im Voraus auf; innerhalb eines 72-Stunden-Fensters lassen sie sich nicht improvisieren.

Drittens: Für regulierte Teams ist dies ein Compliance- und Meldeereignis. Eine root-fähige Kernel-Lücke mit bestätigter Ausnutzung fällt in der EU direkt unter die Erwartungen von NIS2 und DORA an die Sicherheit der Verarbeitung sowie eine zeitnahe, dokumentierte Behebung — und im DACH-Raum unter die entsprechenden nationalen Umsetzungen (in Deutschland das BSI-Gesetz und das NIS2-Umsetzungsgesetz, in Österreich das NISG, in der Schweiz die Meldepflicht für kritische Infrastrukturen beim NCSC). Den Patch-Zeitplan, die Liste betroffener Assets und die Triage-Ergebnisse vorlegen zu können, ist der Nachweis, nach dem Prüfer und Aufsichtsbehörden zuerst fragen — und der sich weit leichter erzeugen lässt, wenn Patch-Management und Logging bereits konstruiert und nicht nachträglich rekonstruiert wurden.

Was jetzt zu tun ist

1. Inventarisieren Sie die Flotte. Erfassen Sie jeden Linux-Host, Cluster-Knoten und CI-Runner und ordnen Sie laufende Kernel-Versionen zu. Die Systeme, die in Ihrem Inventar fehlen, bleiben über die Frist hinaus ungepatcht.
2. Patchen und neu starten. Installieren Sie den korrigierten Kernel Ihrer Distribution und starten Sie neu, oder wenden Sie einen Live-Patch an, wo Ihre Plattform ihn unterstützt. Priorisieren Sie mandantenfähige Knoten, internet-nahe Hosts und CI-Runner, die nicht vertrauenswürdigen Code ausführen.
3. Bauen Sie Container-Images neu. Container erben den Host-Kernel, doch Basis- und Node-Images müssen dort aktualisiert werden, wo sie kernel-gekoppelte Komponenten fixieren; neu bauen und ausrollen, damit nichts auf einem alten Node-Image ausgeliefert wird.
4. Wenden Sie Übergangsmaßnahmen an, falls Sie warten müssen. Wo ein sofortiger Neustart unmöglich ist, reduzieren Sie die Angriffsfläche: kTLS deaktivieren, falls ungenutzt, ARP-umschreibende ebtables-SNAT-Regeln entfernen, die Capability CAP_NET_ADMIN einschränken und das Modul af_alg nach Bewertung der Auswirkungen blockieren. Das sind Notbehelfe, keine Fixes.
5. Suchen, dann testen. Folgen Sie der Triage-Vorgabe der CISA — prüfen Sie die Logs betroffener Hosts auf Spuren früherer Ausnutzung, nicht nur auf den Patch-Stand — und nehmen Sie Kernel- und Rechteausweitungspfade in den Umfang Ihres nächsten Penetrationstests auf, damit die Eskalation von einem Brückenkopf gezielt geprüft wird.

Häufig gestellte Fragen

Quellen

The Hacker News — CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild
CISA — Known Exploited Vulnerabilities Catalog
Cyber Security News — CISA Warns of Linux Kernel Vulnerabilities Actively Exploited in Attacks