CISA gibt Behörden drei Tage zum Patchen von drei ausgenutzten Linux-Kernel-Schwachstellen

CISA hat am 18. September 2026 drei Linux-Kernel-Schwachstellen in seinen Katalog bekannter ausgenutzter Schwachstellen aufgenommen, mit Hinweis darauf, dass alle drei aktiv ausgenutzt werden, und den Bundes-Zivileinheiten bis zum 21. September Zeit zur Behebung gegeben. Das Fenster von rund 72 Stunden ist deutlich kürzer als die drei Wochen, die Behörden für KEV-Einträge üblicherweise erhalten.

Zum Weiterlesen: CISA stuft PolyShell als ausgenutzt ein, während die Magento-Kampagne Hunderte Shops trifft · Microsofts Patchday im Oktober 2026 stellt mit 1.407 Korrekturen einen Rekord auf.

Die drei Schwachstellen sitzen in nicht verwandten Teilen des Kernels, und das macht die Aufnahme ungewöhnlich. Es sind CVE-2025-39682, ein Fehler im TLS-Empfangspfad des Kernels mit Bewertung 9,8; CVE-2026-53266, ein Out-of-Bounds-Write im netfilter-Bridge-Ziel ebtables SNAT mit Bewertung 8,8; und CVE-2025-39964, eine Race-Condition in der kryptografischen Socket-Schnittstelle AF_ALG mit Bewertung 7,8. CISA veröffentlichte sie am selben Tag in zwei Warnungen: eine zu CVE-2025-39682 und eine zweite zu den anderen beiden.

Alle drei wurden gemäß der Binding Operational Directive 26-04 als forensisch zu prüfen gekennzeichnet, was bedeutet, dass Behörden untersuchen müssen, ob ihre Systeme bereits kompromittiert wurden, statt ein Patch als Abschluss der Reaktion zu betrachten. CISA gab nicht bekannt, wer die Schwachstellen ausnutzt, welche Organisationen betroffen sind oder welche Techniken verwendet wurden. Keiner der Einträge wurde als mit Ransomware verbunden markiert.

Drei sehr unterschiedliche Fehler

CVE-2025-39682 ist auf dem Papier der schwerste und am breitesten reichende Fehler. Er betrifft Kernel-TLS, eine Funktion, die die Verarbeitung von TLS-Records zur Effizienz in den Kernel-Speicher verlegt. Der Fehler betrifft den Umgang mit Records der Länge null, die aus der Empfangswarteschlange geholt werden, was eine Annahme brechen kann, die späterer Code darüber trifft, ob Daten bereits entschlüsselt wurden. Red Hats Advisory weist darauf hin, dass die betroffene Logik durch über das Netzwerk eintreffende Daten auf Systemen ausgelöst werden kann, auf denen kTLS an TCP-Sockets gebunden ist, was internetzugewandte Dienste, die auf Kernel-TLS-Beschleunigung setzen, an den Anfang der Prüfliste rückt.

CVE-2026-53266 ist enger, aber schwerwiegender, wenn er greift. Es handelt sich um einen Out-of-Bounds-Write im ebtables-SNAT-Ziel im Bridge-netfilter-Code, der Netzwerkadressen auf gebridgten Verkehr umschreibt. Wenn eine optionale Funktion die ARP-Hardwareadresse des Absenders umschreibt, kann der Kernel in Speicher schreiben, ohne zuvor zu prüfen, ob das Ziel beschreibbar ist, und in einigen Fällen wird dieser Speicher von einem Socket-Puffer-Fragment gestützt, das an eine über eine Splice-Operation importierte Datei gebunden ist. Für die Ausnutzung sind bestimmte Bridge-netfilter-Regeln und in vielen Analysen Berechtigungen äquivalent zu CAP_NET_ADMIN erforderlich, was die betroffene Gruppe einschränkt, aber containerisierte Workloads und Netzwerkappliances einschließt, die diese Berechtigung an Dienstprozesse vergeben.

CVE-2025-39964 ist für einen lokalen Angreifer am zugänglichsten. Es ist eine Race-Condition in AF_ALG, der Schnittstelle, die User-Space-Programmen direkten Zugriff auf kryptografische Kernel-Primitive gibt. Die Schnittstelle erzwang keinen exklusiven Besitz des Schreibpfads auf einem Socket, sodass zwei Threads oder Prozesse, die gleichzeitig schreiben, ihre Operationen ineinander verschachteln und den internen kryptografischen Zustand des Kernels inkonsistent hinterlassen konnten. Das Ergebnis kann ein Absturz oder eine korrumpierte kryptografische Ausgabe sein, ein Datenintegritätsproblem ebenso wie ein Denial-of-Service-Problem. Der Fehler war Berichten zufolge rund 14 Jahre lang im Kernel vorhanden und wurde von STAR Labs gefunden, das im kernelCTF-Wettbewerb von Google eine Rechteausweitung und einen Container-Escape vorführte und angab, keine KI zur Entdeckung genutzt zu haben.

Red Hats Warnung und die Patch-Lage

Red Hat aktualisierte seine Advisorys um den 19. September, um die aktive Ausnutzung anzuerkennen. In den Advisorys zu jedem Fehler erklärte das Unternehmen, die Schwachstelle sei hochriskant und es gebe bekannte öffentliche Exploits, und forderte Kunden auf, sie mit hoher Priorität zu beheben. Patches sind in unterstützten Kernel-Zweigen verfügbar, und Red Hat hat Korrekturen veröffentlicht, darunter RHSA-2025:16880 und RHSA-2025:16904 für CVE-2025-39682 sowie RHSA-2026:36645, RHSA-2026:39082 und RHSA-2026:39083 für CVE-2026-53266.

Für CVE-2026-53266 gibt es eine Abschwächung ohne Patch: das Deaktivieren des Umschreibens der ARP-Hardwareadresse in ebtables-SNAT-Regeln oder das Entfernen von SNAT-Regeln, die auf ARP-Verkehr auf Bridge-Schnittstellen wirken. Für CVE-2025-39964 gibt es laut Red Hat keine funktionierende Abschwächung außer dem Anwenden des Patches. Da die Fehler im Haupt-Kernel und nicht in der Paketierung einer einzelnen Distribution liegen, erstreckt sich die Exposition in unterschiedlichem Maß auf RHEL, Ubuntu, Debian und andere vom Kernel abgeleitete Systeme, je nach Kernelversion und Konfiguration des jeweiligen Systems.

Ein Detail sollte man von der Herstellerkommunikation trennen. CVE-2026-53266 wurde nicht mit öffentlichem Exploit-Code demonstriert, und Analysen haben die Kette zur Rechteausweitung eher in Analogie zu Dirty Pipe abgeleitet als durch einen funktionierenden Angriff gezeigt. Das widerspricht nicht der Feststellung von CISA, dass der Fehler ausgenutzt wurde, aber es bedeutet, dass Verteidiger das öffentliche Exploit-Bild als unvollständig betrachten sollten.

Warum die Frist so kurz war

BOD 26-04 hat verändert, wie CISA das föderale Patchen priorisiert. Statt Schwachstellen allein nach CVSS-Wert zu sortieren, wägt es vier Variablen ab, darunter, ob ein Fehler bekanntermaßen ausgenutzt wird. Die Linux-Kernel-Aufnahmen sind eine klare Illustration: CVE-2025-39964 würde in einem score-zentrierten Verfahren wie ein lokaler Fehler mittlerer Schwere erscheinen, doch bestätigte Ausnutzung und die forensische Prüfpflicht setzen ihn auf dieselbe 72-Stunden-Uhr wie einen Fehler mit Bewertung 9,8.

Für Organisationen außerhalb der US-Bundesregierung ist die KEV-Listung ein Signal und kein Auftrag. Die betroffenen Kernel-Funktionen sind verbreitet genug, dass der praktische Rat einfach ist: Linux-Hosts und Container mit anfälligen Kernelversionen identifizieren, Systeme priorisieren, bei denen kTLS an TCP-Sockets gebunden ist, bei denen Bridge-netfilter-Regeln ebtables SNAT mit ARP-Umschreibung verwenden und bei denen Workloads AF_ALG direkt aufrufen. Da das Patchen eines Pakets einen laufenden Kernel nicht verändert, sollten Teams nach dem Update die Kernelversion bestätigen und bei Bedarf neu starten.

Eine praktische Checkliste

Die drei Fehler erfordern unterschiedliche Voraussetzungen, um ausnutzbar zu sein, sodass Verteidiger triagieren können, statt in Panik zu geraten. Der Kernel-TLS-Fehler ist derjenige, der auf internetzugewandten Systemen priorisiert werden sollte, weil er laut Red Hat durch Netzwerkverkehr auf Hosts ausgelöst werden kann, bei denen kTLS an TCP-Sockets gebunden ist. Dienste, die TLS zur Leistungssteigerung im Kernel terminieren, darunter einige Proxys, Load Balancer und Speichersysteme, sind die erste Adresse. Ob kTLS genutzt wird, ist eine Konfigurationsfrage, und Hosts, die es nicht nutzen, sind über diesen Pfad nicht exponiert.

Der ebtables-Fehler ist situativer. Er benötigt Bridge-netfilter-Regeln, die SNAT mit dem Umschreiben der ARP-Hardwareadresse ausführen, und die Ausnutzungsanalysen legen nahe, dass er zudem Berechtigungen äquivalent zu CAP_NET_ADMIN erfordert. Container-Hosts, Virtualisierungsknoten und Netzwerkappliances, die diese Berechtigung an Dienstprozesse weitergeben, sind am wahrscheinlichsten betroffen. Eine kurzfristige Abschwächung ist, das Umschreiben der ARP-Hardwareadresse in ebtables-SNAT-Regeln zu deaktivieren oder SNAT-Regeln zu entfernen, die auf ARP-Verkehr auf Bridge-Schnittstellen wirken.

Die AF_ALG-Race ist ein lokales Problem, was bedeutet, dass der Angreifer bereits laufenden Code auf dem Host benötigt. Sie zählt am meisten in Mandanten- und Container-Umgebungen, in denen ein Prozess mit geringen Rechten die kryptografische Socket-Behandlung des Kernels überholen könnte. Es gibt keine Abschwächung außer dem Patch, und da der Fehler eine Race-Condition ist, variiert seine praktische Ausnutzbarkeit mit Workload und Timing.

Bei allen drei ist die forensische Prüfpflicht der Teil, der leicht übersprungen wird. Ein Patch schließt die Tür, sagt aber nicht, ob jemand hindurchgegangen ist. Organisationen, die die KEV-Frist als Ende der Aufgabe betrachten, könnten Beweise einer früheren Kompromittierung übersehen, und genau das soll die Richtlinie von CISA verhindern.

Was zu beobachten ist

Die erste Frage ist, was Angreifer mit diesen Fehlern tatsächlich tun. CISA hat keine Indikatoren für Kompromittierung oder Threat-Intelligence-Details veröffentlicht, sodass Verteidiger allein mit der KEV-Listung arbeiten. Fördert die forensische Prüfung bei Bundesbehörden Beweise für eine Ausnutzung zutage, könnten weitere Details folgen.

Die zweite ist, ob die Fehler zusammen genutzt wurden. Der Kernel-TLS-Fehler ist in der richtigen Konfiguration aus der Ferne auslösbar, der ebtables-Fehler kann zur Rechteausweitung führen, und der AF_ALG-Fehler ist eine lokale Race. Eine Kette, die aus der Ferne beginnt und lokal Rechte ausweitet, wäre gefährlicher als jeder einzelne Fehler, und keine öffentliche Berichterstattung hat sie bislang verbunden.

Die dritte ist das breitere Muster. Drei nicht verwandte Kernel-Fehler, gleichzeitig ausgenutzt, mit einer 72-Stunden-Frist, sind eine Erinnerung daran, dass die Angriffsfläche des Linux-Kernels groß ist und Patch-Zyklen für Infrastruktursoftware der Ausnutzung hinterherlaufen können. Für Teams, die Linux im großen Maßstab betreiben, lautet die nützliche Lehre, die Lücke zwischen einem Kernel-Advisory und einem Neustart zu verkleinern, denn die nächste KEV-Aufnahme ist nur eine Frage des Wann, nicht des Ob.

Cover: Wikimedia-Commons-Foto eines Arch-Linux-System-Updates über pacman auf einem Acer-Laptop von Solijon Solayev (CC BY-SA 4.0).