CISA nimmt drei Linux-Kernel-Lücken in den KEV-Katalog auf

Die US-Cybersicherheitsbehörde CISA hat am 18.09.2026 drei Schwachstellen im Linux-Kernel in ihren Katalog der bekannten ausgenutzten Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen und verweist dabei auf Belege für aktive Ausnutzung. Betroffen sind der TLS-Empfangspfad des Kernels, das SNAT-Target der ebtables-Bridge-Firewall und die Krypto-Schnittstelle AF_ALG. Für US-Bundesbehörden gilt laut Binding Operational Directive BOD 26-04 eine Frist bis zum 21.09.2026.

Die entscheidende Einordnung für den Betrieb: Alle drei Lücken sind lokale Angriffe. Keine davon erlaubt eine Codeausführung aus dem Internet ohne vorherigen Zugriff auf das System. Wer einen einzelnen Webserver ohne weitere Nutzerkonten betreibt, muss heute nicht in den Notfallmodus wechseln, sondern kann die Kernel-Updates im nächsten regulären Wartungsfenster einspielen. Wer dagegen Multi-User-Systeme, Shared Hosting, Build-Server, CI-Runner oder Container-Plattformen betreibt, auf denen fremder oder halbvertrauter Code läuft, sollte den Patchstand kurzfristig prüfen. Dort sind solche Lücken die zweite Stufe nach einem erfolgreichen Erstzugriff.

Was ist passiert?

CISA hat am 18.09.2026 die drei CVE-Einträge CVE-2025-39682, CVE-2026-53266 und CVE-2025-39964 in den KEV-Katalog eingetragen. Die Aufnahme in diesen Katalog erfolgt nur, wenn der Behörde Belege für eine tatsächliche Ausnutzung vorliegen. Die damit verbundene Direktive BOD 26-04 verpflichtet US-Bundesbehörden, die betroffenen Systeme bis zum 21.09.2026 zu aktualisieren oder außer Betrieb zu nehmen. Für Unternehmen außerhalb der US-Verwaltung ist die Direktive nicht bindend, der KEV-Katalog gilt aber seit Jahren als praxistaugliche Priorisierungsliste.

Red Hat hat die Advisories zu allen drei Schwachstellen am 19.09.2026 um 02:00 UTC aktualisiert und die aktive Ausnutzung anerkannt. Die Formulierung im Advisory lautet: "This CVE is high risk and there are known public exploits leveraging this vulnerability", verbunden mit der Empfehlung, die Lücke mit hoher Priorität zu behandeln.

Wichtig und ehrlich gesagt: Es gibt bislang keine öffentlichen Details dazu, wie die drei Lücken konkret ausgenutzt werden. Es ist auch nicht bestätigt, ob sie als eine zusammenhängende Angriffskette genutzt werden oder unabhängig voneinander. Wer belastbare Indikatoren für die eigene Erkennung sucht, findet derzeit keine öffentlich dokumentierten Angriffsmuster, sondern nur die Behördenbestätigung, dass Ausnutzung stattfindet.

Die drei Lücken im Detail

CVE-2025-39682 betrifft den TLS-Empfangspfad im Kernel. Die Schwachstellenklasse lautet Improper Check for Unusual or Exceptional Conditions. Lokal authentifizierte Nutzer können damit Speicherinhalte offenlegen oder einen Denial of Service auslösen. Der zugehörige Kernel-Fix trägt die Beschreibung "tls: fix handling of zero-length records on the rx_list". Aus dem Kernel-Changelog geht hervor, dass jeder Aufruf von recvmsg() entweder nur zusammenhängende DATA-Records oder genau einen Nicht-DATA-Record verarbeiten darf. Records der Länge null auf der rx_list wurden dabei falsch behandelt.

CVE-2026-53266 ist ein Out-of-bounds Write im SNAT-Target von ebtables, das beim Umschreiben der ARP-Hardware-Adresse auftritt. Möglich sind unerwartetes Systemverhalten, Denial of Service oder eine lokale Rechteausweitung. Der Kernel-Fix heißt "netfilter: bridge: make ebt_snat ARP rewrite writable". Technisch hält das SNAT-Target das Umschreiben der Ethernet-Quelladresse hinter skb_ensure_writable(skb, 0) ab, weil an den Bridge-ebtables-Hooks der Ethernet-Header über skb_mac_header() beziehungsweise eth_hdr() adressiert wird, während skb->data bereits auf die Nutzlast zeigt. Das optionale Umschreiben der ARP-Sender-Hardware-Adresse war von dieser Absicherung nicht abgedeckt. Red Hat ordnet die Lücke der Schwachstellenklasse CWE-825 zu.

CVE-2025-39964 ist eine Race Condition, die gleichzeitige Schreibzugriffe auf denselben AF_ALG-Socket erlaubt. AF_ALG ist die Socket-Schnittstelle, über die Anwendungen die Kryptofunktionen des Kernels nutzen. Ein lokaler Angreifer kann das System zum Absturz bringen oder die Ergebnisse kryptografischer Operationen verfälschen. Es geht also um Verfügbarkeit und Datenintegrität, nicht um direkte Rechteausweitung. Der Fix führt ein neues Feld ctx->write ein, das exklusiven Schreibbesitz markiert. Red Hat beschreibt die Auswirkung so, dass bei verschachtelten gleichzeitigen Schreibzugriffen auf denselben AF_ALG-Socket die Daten unvorhersehbar vermischt werden und der interne Socket-Zustand inkonsistent werden kann.

CVE	Komponente	CVSS laut TheHackerNews	Red Hat CVSS3 und Einstufung	Öffentlich seit
CVE-2025-39682	TLS-Empfangspfad, rx_list	9.8	7.0, Moderate	05.09.2025
CVE-2026-53266	netfilter, ebtables SNAT, ARP-Rewrite	8.8	7.5, Important	01.06.2026
CVE-2025-39964	crypto, AF_ALG, af_alg_sendmsg	7.8	5.5, Moderate	13.10.2025

Wer ist betroffen?

Betroffen sind Linux-Systeme mit einem Kernel, in dem die jeweiligen Fixes noch nicht eingespielt sind. Da alle drei Fehler in Kernkomponenten des Kernels sitzen, sind grundsätzlich alle gängigen Distributionen betroffen, solange sie keinen gepatchten oder zurückportierten Kernel ausliefern. Die Betroffenheit hängt aber stark vom Einsatzszenario ab:

• Deutlich erhöhtes Risiko: Shared Hosting, Terminalserver und andere Multi-User-Systeme, auf denen sich mehrere nicht vollständig vertrauenswürdige Personen anmelden.
• Deutlich erhöhtes Risiko: Build-Server, CI-Runner und Entwicklungsumgebungen, die fremden oder aus Repositories gezogenen Code ausführen.
• Erhöhtes Risiko: Container-Plattformen und Kubernetes-Knoten, weil Container den Kernel des Hosts teilen und eine Rechteausweitung im Kernel die Containergrenze relativiert.
• Erhöhtes Risiko: Systeme, auf denen ebtables oder Bridge-Firewalling aktiv genutzt wird, etwa Virtualisierungshosts mit gebrückten Netzwerken.
• Geringeres Risiko: Einzelne Anwendungs- oder Webserver ohne interaktive Nutzerkonten, bei denen nur Administratoren per SSH Zugriff haben.
• Geringeres Risiko: Appliances und eingebettete Systeme ohne Shell-Zugang für Endnutzer, sofern der Hersteller die Komponenten nicht exponiert.

Wer wahrscheinlich nicht dringend handeln muss: kleine Umgebungen mit einem oder zwei Linux-Servern, auf denen ausschließlich das eigene Admin-Team ein Konto hat und keine fremden Workloads laufen. Dort bleibt die Aktualisierung Pflicht, aber sie gehört in das reguläre Wartungsfenster und nicht in eine Sondereskalation.

Wie kritisch ist das?

Die von TheHackerNews genannten CVSS-Werte liegen mit 9.8, 8.8 und 7.8 deutlich über den Bewertungen, die Red Hat für die eigenen Produkte vergibt (7.0, 7.5 und 5.5). Diese Abweichung ist kein Widerspruch und kein Fehler, sondern Alltag im Schwachstellenmanagement. NVD-Werte werden oft unter der ungünstigsten denkbaren Annahme vergeben, etwa ohne Berücksichtigung, ob eine Komponente in der Standardkonfiguration einer Distribution überhaupt erreichbar ist. Distributionen bewerten dagegen ihre eigene Auslieferung: Welche Kernel-Konfiguration ist aktiv, welche Module sind geladen, welche Härtungsmassnahmen greifen bereits.

Praktische Konsequenz für Admins: Verlassen Sie sich bei der Priorisierung im Zweifel auf die Einstufung der eingesetzten Distribution, nicht auf den höchsten öffentlich zitierten Wert. Red Hat stuft CVE-2026-53266 als "Important" und die beiden anderen als "Moderate" ein und nennt für CVE-2026-53266 den Vektor CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Gleichzeitig hat Red Hat bei allen drei Einträgen den Hinweis auf bekannte öffentliche Exploits ergänzt. Diese Kombination aus moderatem Basiswert und bestätigter Ausnutzung ist genau der Fall, in dem der reine CVSS-Wert für die Priorisierung nicht ausreicht.

Technisch bleibt es bei der nüchternen Einordnung: lokale Rechteausweitung, Denial of Service und Informationsabfluss. Das ist ernst, aber es ist nicht mit einer per Internet erreichbaren Remote-Code-Execution auf einem Edge-Gerät vergleichbar. Ein Angreifer braucht zuerst einen Fuß auf dem System.

Vier weitere lokale Root-Exploits im Umfeld

Zeitlich fast parallel hat der Sicherheitsforscher Asim Manizada vier weitere lokale Rechteausweitungs-Lücken im Linux-Kernel offengelegt: CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow), CVE-2026-68121 (PPPoEject) und CVE-2026-74469 (DiagSpill). Für diese vier wurden öffentliche Exploits veröffentlicht. Sie gehören nicht zum KEV-Eintrag vom 18.09.2026, erhöhen aber den Druck auf denselben Patchpfad, weil auch hier der Kernel das Ziel ist und auch hier lokaler Zugriff die Voraussetzung ist. Die Details dazu stehen in einem eigenen Artikel, der weiter unten verlinkt ist.

Für die Planung heißt das: Wer ohnehin ein Kernel-Update einplant, sollte beide Themenblöcke in einem Wartungsfenster abarbeiten, statt zweimal neu zu starten.

Was sollten Admins jetzt tun?

• Kernel-Version erheben. Auf jedem Linux-System uname -r ausführen und den Stand gegen die Sicherheitsmeldungen der eingesetzten Distribution abgleichen. Ohne diese Bestandsaufnahme ist jede weitere Bewertung Raten.
• Distributionspatches einspielen. Die Fixes kommen über die regulären Kernel-Pakete der Distribution, nicht über eine separate Notfallauslieferung. Nach dem Update ist in der Regel ein Neustart nötig, damit der neue Kernel aktiv wird.
• Livepatching prüfen. Wo Neustarts teuer sind, klären, ob die eingesetzte Distribution ein Livepatching-Angebot hat und ob die betroffenen Fixes davon abgedeckt sind. Livepatching deckt nicht jeden Kernel-Fix ab, das muss im Einzelfall geprüft werden.
• Hochrisikosysteme zuerst. Reihenfolge festlegen: erst Systeme mit mehreren Nutzerkonten, Shared Hosting, Build-Server und CI-Runner, dann Container-Hosts, danach der Rest.
• Nicht benötigte Kernel-Module prüfen. Klären, ob AF_ALG und ebtables auf dem jeweiligen System überhaupt gebraucht werden. Nicht benötigte Funktionalität zu deaktivieren verkleinert die Angriffsfläche, ersetzt den Patch aber nicht.
• Logs und EDR auswerten. Gezielt nach Hinweisen auf lokale Eskalationsversuche suchen: unerwartete Prozessabstürze, Kernel-Oops-Meldungen, auffällige Compiler-Aufrufe in Nutzerverzeichnissen, ungewöhnliche Sitzungen auf Mehrbenutzersystemen.
• Zugangswege einschränken. Prüfen, wer auf den betroffenen Systemen überhaupt eine Shell braucht. Jedes entfernte Konto senkt die Wahrscheinlichkeit, dass eine lokale Lücke überhaupt erreichbar ist.
• Dokumentieren. Patchstand und Entscheidung je System festhalten, auch bei bewusster Verschiebung. Das ist bei einer späteren Prüfung der Unterschied zwischen Nachlässigkeit und begründeter Risikoentscheidung.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist der Fall überschaubar, wenn die Linux-Landschaft überschaubar ist. Ein Fileserver, ein Anwendungsserver und ein Backup-Ziel, jeweils nur vom Admin-Team erreichbar, ergeben ein deutlich anderes Risikoprofil als eine Hosting-Umgebung mit Kundenzugängen. Der ehrliche Rat lautet daher: Bestand erheben, Risikoklassen bilden, dann patchen. Eine pauschale Sondereskalation quer durch alle Systeme ist bei lokalen Lücken selten die wirtschaftlich richtige Antwort.

Anders sieht es aus, wo fremder Code ausgeführt wird. Build-Pipelines, die Abhängigkeiten aus öffentlichen Registries ziehen, sind ein realistischer Erstzugriffspfad. Kombiniert mit einer lokalen Kernel-Lücke wird daraus die vollständige Übernahme des Build-Hosts, inklusive der dort hinterlegten Signaturschlüssel und Deployment-Zugänge. Genau diese Kombination macht die aktuellen Meldungen relevant.

Für die mittelfristige Planung lohnt es sich, den KEV-Katalog fest in den eigenen Patchprozess einzubauen, statt auf Einzelmeldungen zu reagieren. Er ist kürzer als jede vollständige CVE-Liste und enthält per Definition nur, was tatsächlich ausgenutzt wird.

Passende Anleitungen auf S-EDV

• Öffentliche Exploits für vier Linux-Kernel-Lücken zur lokalen Root-Eskalation: Details zu DirtyAH6, TUNderflow, PPPoEject und DiagSpill aus Ereignis B.
• CVE-2022-0492 im CISA-KEV-Katalog: Linux-Kernel und Container-Escape: warum Kernel-Lücken die Containergrenze aushebeln.
• CISA-KEV-Katalog als Grundlage der Patch-Priorisierung: wie sich der Katalog in den eigenen Patchprozess einbauen lässt.

Quellen

• CISA, Known Exploited Vulnerabilities Catalog
• TheHackerNews vom 19.09.2026 zu den drei Linux-Kernel-Lücken
• Red Hat Security, CVE-2026-53266
• Red Hat Security, CVE-2025-39682
• Red Hat Security, CVE-2025-39964