Ende Oktober 2026 wurden innerhalb weniger Tage zwei Schwachstellen bekannt, die fast jede Unternehmens-IT betreffen. Die eine sitzt im TCP-Stack des Linux-Kernels, die andere in einer Kompressionsbibliothek (Stichwort HTTP2Shell), die kaum jemand bewusst installiert hat. Beide zeigen, dass Sicherheit heute weniger eine Frage einzelner Tools ist als eine Frage des Betriebs: Wer seine Systeme kennt, Updates planbar einspielt und rund um die Uhr reagieren kann, ist klar im Vorteil.
Lücke 1: Der Linux-Kernel selbst (CVE-2026-98432)
Am 15. Oktober wurde eine Use-after-free-Schwachstelle im IPv4-TCP-Stack des Linux-Kernels veröffentlicht. Der Fehler steckt seit einer Codeänderung aus dem Jahr 2015 im Kernel und betrifft alle Versionen ab 4.4. Ein Angreifer kann ihn ohne Anmeldung über das Netzwerk auslösen, indem er speziell präparierte Verbindungsanfragen sendet. Die Kernel-Entwickler bewerten die Lücke mit einem CVSS-Wert von 9.8, also kritisch. Red Hat stuft sie vorläufig mit 8.1 etwas niedriger ein, weil für einen Angriff eine Race Condition gewonnen werden muss.
Brisant wurde der Fall am 27. Oktober: Forscher von Anthropic zeigten, dass sich die Lücke nutzen lässt, um ohne Zugangsdaten Root-Rechte auf einem System zu erlangen. Voraussetzung in dieser Demonstration war ein Dienst mit aktiviertem Multipath-TCP (MPTCP), das etwa Go-Programme ab Version 1.24 standardmäßig nutzen. Eine Ausnutzung durch Angreifer in freier Wildbahn ist bisher nicht bestätigt.
Bei den Patches zeigt sich ein bekanntes Muster: Der Fix war im offiziellen Kernel schnell verfügbar, und Debian lieferte für Version 12 und 13 zügig aktualisierte Pakete aus. Für RHEL 8, 9 und 10 waren am 30. Oktober dagegen noch keine korrigierten Pakete gelistet, und auch bei Ubuntu war der Status zu diesem Zeitpunkt nicht bestätigt. Unternehmen mit großen Enterprise-Linux-Umgebungen müssen solche Zeiträume mit Übergangsmaßnahmen überbrücken.
Lücke 2: HTTP2Shell, die versteckte Abhängigkeit (CVE-2026-111497)
Die zweite Schwachstelle betrifft Brotli, ein von Google entwickeltes Kompressionsverfahren, das im Web weit verbreitet ist. Im Decoder der Versionen 1.0.3 bis 1.2.0 kann ein Angreifer mit präparierten Daten Speicher überschreiben und unter Umständen Code ausführen. Die Lücke wurde am 22. Oktober veröffentlicht und mit einem CVSS-v4-Wert von 9.2 bewertet. In Sicherheitskreisen läuft sie unter Namen wie HTTP2Shell oder Node2Shell.
Das Tückische daran ist, dass Brotli selten bewusst eingesetzt wird. Die Bibliothek steckt in Node.js (Versionen 22, 24 und 26), in Python-Paketen, die von gängigen HTTP-Clients automatisch genutzt werden, in den Proxys Envoy und Istio, in Java-Bibliotheken wie brotli4j und in vielen weiteren Komponenten. Betroffen sind Anwendungen, die Brotli-komprimierte Daten aus nicht vertrauenswürdigen Quellen entpacken. Das gilt etwa für Webserver, die komprimierte Anfragen annehmen, und für Dienste, die Inhalte von fremden Servern abrufen, zum Beispiel Webhooks oder Crawler.
Auch hier hinken die Distributionen hinterher: Debian und Alpine hatten Updates ausgeliefert, für Ubuntu, RHEL und SUSE gab es am 23. Oktober noch keine Pakete. Mehrere Sicherheitsanbieter und Fachmedien berichten inzwischen, dass die US-Behörde CISA vor laufenden Angriffen auf die Lücke warnt. Wer Node.js- oder Python-Anwendungen mit Kontakt zum Internet betreibt, sollte das Thema daher mit hoher Priorität behandeln.
Was beide Fälle gemeinsam haben
Auf den ersten Blick haben eine Kernel-Lücke und ein Fehler in einer Kompressionsbibliothek wenig miteinander zu tun. Für den Betrieb zeigen sie aber dieselben vier Lehren:
- Man kann nur schützen, was man kennt.
Ohne aktuelles Inventar von Kernelversionen, Laufzeitumgebungen und Bibliotheken dauert schon die Frage „Sind wir betroffen?“ Tage statt Stunden. - Zwischen Fix und Patch liegt eine Lücke.
Upstream-Korrekturen erreichen Enterprise-Distributionen oft erst mit Verzögerung. Diese Zeit muss mit Workarounds und erhöhter Überwachung abgesichert werden. - Das Zeitfenster wird kürzer.
Wenn Forscher mit KI-Unterstützung innerhalb weniger Tage einen funktionierenden Exploit vorführen, ist davon auszugehen, dass Angreifer ähnlich schnell sind. Monatliche Patchzyklen ohne Notfallprozess reichen dafür nicht mehr aus. - Aktualisierung braucht Betriebsdisziplin.
Ein Kernel-Update wirkt erst nach einem Neustart. Wer Wartungsfenster, Clusterrotationen und Rollbacks nicht eingeübt hat, schiebt kritische Updates auf, weil sie zu riskant erscheinen.
Was Sie jetzt konkret tun sollten
Erfassen Sie Kernelversionen aller Linux-Systeme sowie alle Vorkommen von Brotli in Node.js-, Python-, Java- und Container-Umgebungen. Denken Sie dabei auch an Container-Images und an Pakete, die nur indirekt mitinstalliert wurden.
Systeme mit direktem Kontakt zum Internet zuerst. Für den Kernel gilt: Update installieren, neu starten und die laufende Version kontrollieren.
Für die Kernel-Lücke lässt sich MPTCP deaktivieren (net.mptcp.enabled=0), was den bekannten Angriffsweg schließt, die Lücke selbst aber nicht. Für HTTP2Shell können Anfragen mit „Content-Encoding: br“ an WAF, Reverse Proxy oder Ingress abgewiesen und Brotli-Filter in Envoy oder Istio deaktiviert werden.
Achten Sie auf ungewöhnliche Prozesse, neue Benutzer, unerwartete ausgehende Verbindungen und Abstürze von Diensten.
Die Lage ändert sich täglich. Prüfen Sie regelmäßig die Advisories Ihrer Distribution und von CERT.at.
Laufende Aktualisierung ist ein Prozess, kein Projekt
Viele Unternehmen behandeln Updates noch immer als Einzelaufgabe, die erledigt wird, wenn Zeit bleibt. Die beiden aktuellen Fälle zeigen, warum das nicht mehr reicht. Verlässlich wird der Betrieb erst, wenn einige Grundlagen dauerhaft verankert sind: ein aktuelles Inventar inklusive Softwarestücklisten (SBOM), feste Patchfenster mit einem klar definierten Notfallweg für kritische Lücken, getestete Neustart- und Rollback-Verfahren, Monitoring rund um die Uhr und eine Lebenszyklusplanung, die Supportenden von Betriebssystemen und Plattformen rechtzeitig berücksichtigt.
Dazu kommt der regulatorische Rahmen. Seit 1. Oktober 2026 gilt in Österreich das NISG 2026, das von betroffenen Einrichtungen ein wirksames Risikomanagement verlangt. Schwachstellen- und Patchmanagement gehört in der Praxis zum Kern davon. Wer hier sauber dokumentierte Prozesse hat, ist nicht nur besser geschützt, sondern kann seine Maßnahmen auch nachweisen.
Klingt spannend? Reden wir darüber
ONTEC betreibt geschäftskritische Infrastruktur für Unternehmen aus Energie, Bahn, Logistik, Finanzwesen und öffentlicher Verwaltung. Unser Managed-Services-Team ist rund um die Uhr erreichbar und reagiert innerhalb von 30 Minuten. Wir kümmern uns um Linux-Umgebungen, Kubernetes-Plattformen, Datenbanken und Applikationsserver und übernehmen Patch- und Schwachstellenmanagement als laufenden Prozess. Unser IT Health Check zeigt Ihnen, wo veraltete Komponenten, fehlende Updates oder unklare Abhängigkeiten ein Risiko darstellen. Als nach ISO 27001 zertifizierter und nach ISAE 3402 geprüfter Dienstleister arbeiten wir nach dokumentierten und auditierbaren Abläufen.
Sie möchten wissen, ob Ihre Systeme von den aktuellen Lücken betroffen sind, oder Ihr Patchmanagement auf ein verlässliches Fundament stellen? Sprechen Sie uns an. Wir unterstützen Sie gerne und stehen Ihnen für Fragen jederzeit zur Verfügung.
Hannes Gruber
ONTEC AG
Kundenorientierung bedeutet für mich sich in die Lage des Kunden versetzen zu können. Genaues Zuhören, verstehen und ein fachlich top aufgestelltes Team sind hierbei entscheidend, um den Kunden die optimale Lösung anzubieten.