CISA hat am 19. September 2026 drei Linux-Kernel-Schwachstellen in den Known Exploited Vulnerabilities (KEV)-Katalog aufgenommen und dabei bestätigte aktive Ausnutzung im laufenden Betrieb dokumentiert. Eine der drei Lücken, CVE-2025-39964, existierte seit 14 Jahren im Kernel, bevor das offensive Security-Unternehmen STAR Labs sie identifizierte und einen Proof-of-Concept für Privilege Escalation und Container Escape vorlegte. CISA verlangt für alle betroffenen Assets eine forensische Triage und hat US-Behörden unter Berufung auf die Binding Operational Directive 26-04 eine 72-Stunden-Frist zur Behebung gesetzt. (BleepingComputer, 21.09.2026)

Für einen Betrieb mit 10 bis 100 Mitarbeitern heißt das konkret: Jede Linux-Instanz im Produktivbetrieb – Webserver, Datenbank, Container-Host, Reverse Proxy – ist potenziell betroffen. Die drei Lücken treffen drei voneinander unabhängige Kernel-Subsysteme, eine einzelne Konfigurationsänderung schafft daher keine Abhilfe. Im schlechtesten Fall eskaliert ein lokaler Angreifer mit begrenzten Rechten zu Root, kryptographische Operationen liefern stillschweigend falsche Ergebnisse, oder das System crasht unvorhersehbar. Auffällig ist, dass man all das erst bemerkt, wenn es bereits passiert ist: ein TLS-Handshake, der korrupte Daten liefert, sieht von außen aus wie ein normaler Server. Eine Datenbank, die plötzlich unverschämt lange braucht, ein Container, der ohne erkennbaren Grund fällt – das sind die Symptome, die nach der Ausnutzung kommen, nicht vor ihr.

Drei Lücken, drei Subsysteme, ein gemeinsames Problem

CVE-2025-39682 (TLS-Empfangspfad): Die Funktion tls_sw_recvmsg() im Modul net/tls/tls_sw.c verarbeitet TLS-Records auf der Empfangsseite. Wird ein null-langes Record aus der rx_list-Queue gezogen, umgeht die Typwechsel-Erkennung ihre Logik vollständig. In TLS 1.3 – wo der Record-Typ erst nach Entschlüsselung bekannt ist – kann ein nachfolgendes Record eines anderen Typs unter falschen Annahmen verarbeitet werden. Im Zero-Copy-Modus (darg.zc == 1) wird zusätzlich der Anchor-Socket-Buffer in die rx_list eingereiht, was den Referenzzähler korrupt macht und eine Use-After-Free-Fehlerlage erzeugt. Betroffen sind Kernel-Versionen 6.0 bis 6.16.3 sowie 6.17-rc1 und 6.17-rc2. TechTimes liefert hier die detaillierteste technische Aufschlüsselung.

CVE-2026-53266 (ebtables SNAT, veröffentlicht am 25. Juni 2026): In der Bridge-Netfilter-Subsystem, konkret im ebt_snat-Target, fehlt ein Writability-Check vor dem Schreiben der ARP-Sender-MAC-Adresse. Die Funktion skb_header_pointer() liefert nur Lesezugriff; der darauffolgende Aufruf von skb_store_bits() schreibt jedoch direkt in die Zielregion. Wird die ARP-Adresse in einem nicht-linearen Socket-Buffer-Fragment gehalten, das auf eine splice-importierte Datei-Seite zeigt, schreibt der Kernel in fremden Speicher – eine Out-of-Bounds-Write-Fehlerlage mit dokumentiertem Pfad zur lokalen Privilegieneskalation. Der Forscher Kimmo Suominen hat auf GitHub eine technische Analyse und einen Patch-Status-Tracker veröffentlicht; die darin skizzierte Exploitation-Chain ist jedoch per Analogie zu Dirty Pipe abgeleitet und nicht durch öffentlichen Exploit-Code belegt.

CVE-2025-39964 (AF_ALG Race Condition, veröffentlicht am 13. Oktober 2025): Das AF_ALG-Interface erlaubt zwei gleichzeitige Writer auf demselben Socket. Request-Payloads aus separaten Threads können sich in der kryptographischen Verarbeitungsqueue des Kernels unvorhersehbar überlappen. Ergebnis: korrupte kryptographische Ausgabe oder Kernel-Panic. Betroffen sind Kernel ab 2.6.38 bis 6.16.9 und 6.17-rc6 – ein deutlich älterer und breiterer Angriffsvektor, als die CVSS-Bewertung vermuten lässt.

Zur CVSS-Bewertung: Hier widersprechen sich die Quellen. The Hacker News listet CVE-2025-39682 mit CVSS 9.8, während TechTimes einen Wert von 7.1 (High) angibt. Für CVE-2025-39964 nennt TechTimes drei verschiedene Scores: NVD 3.3 (Low), Red Hat 5.5 (Medium), cve.org 7.8 (High). Die KEV-Eintragung selbst ist unabhängig von der CVSS-Zahl das maßgebliche Signal: CISA bestätigt aktive Ausnutzung. Red Hat hat für alle drei Lücken Patches veröffentlicht – unter den Advisories RHSA-2025:16880 und RHSA-2025:16904 (CVE-2025-39682) sowie RHSA-2026:36645, RHSA-2026:39082 und RHSA-2026:39083 (CVE-2026-53266) – und bestätigt für CVE-2025-39682 und CVE-2026-53266 bekannte öffentliche Exploits. Bisher ist keine Ausnutzung durch Ransomware-Gruppen dokumentiert.

Was jetzt zu tun ist

1. Kernel-Versionen inventarisieren. Auf jeder Linux-Instanz im Bestand uname -r auslesen und gegen die betroffenen Bereiche prüfen: CVE-2025-39682 betrifft Kernel 6.0 bis 6.16.3, CVE-2025-39964 reicht zurück bis 2.6.38. Wer keine aktuelle Inventarliste hat, sollte sie jetzt anlegen. Die 72-Stunden-Frist gilt formal für US-Behörden, aber die aktive Ausnutzung kennt keine Staatsgrenze.
2. Vendor-Patch einspielen und Reboot einplanen. Alle drei Fixes erfordern ein Kernel-Update mit anschließendem Neustart – es gibt keinen reinen Konfigurations-Workaround, der die Lücke schließt. Für Red-Hat-Systeme: die genannten RHSA-Advisories abgleichen. Für Ubuntu-Systeme: Canonical-Livepatch-Verfügbarkeit prüfen, ob ein Reboot erspart bleibt. Den Reboot jetzt terminieren, nicht erst nach dem nächsten Wartungsfenster.
3. Exposition einschränken, bis der Patch sitzt. Prüfen, ob kTLS aktiviert ist (identifizierbar über setsockopt(SOL_TLS)-Aufrufe in der Anwendung), ob ebtables-SNAT-Regeln für ARP-Rewriting konfiguriert sind und ob AF_ALG-Module geladen sind. Als Übergangsmassnahme kann das af_alg-Modul per Blacklist vom Laden abgehalten werden – das deaktiviert allerdings Kernel-Kryptographie für Anwendungen, die darauf angewiesen sind. CAP_NET_ADMIN-Zugriff auf ebtables-Regeln auf vertrauenswürdige Prozesse beschränken.

Das Ärgerliche an Kernel-Lücken dieser Art: Ein TLS-Handshake, der stillschweigend korrupte Daten liefert, sieht von außen aus wie ein normaler Server. Man merkt es erst, wenn die Datenbank unverschämt lange braucht oder ein Container ohne erkennbaren Grund fällt. Wer jetzt unsicher ist, ob die eigenen Linux-Instanzen sauber gepatcht sind und ob kTLS oder ebtables überhaupt im Spiel sind, hat damit schon die richtige Frage gestellt. Wenn Sie möchten, schauen wir uns das einmal konkret an – Kernel-Versionen, kTLS-Exposition, ebtables-Regeln – und sagen Ihnen, wo Sie stehen. Kontakt.

Beitragsbild: Maarten Ceulemans auf Pexels