Nachdem wir in unserem Beitrag „Copy Fail & Dirty Frag: Statusbericht zu den aktuellen Kernel-Sicherheitslücken“ bereits über zwei kritische Schwachstellen berichtet hatten, kamen mit Fragnesia, CIFSwitch und pedit COW drei weitere hinzu, deren Angriffswege wir ebenfalls durch das Sperren betroffener Kernel-Module schließen konnten. Nun sind mit Januscape und GhostLock zwei neue Sicherheitslücken aufgetaucht, die sich nur durch die Installation neuer Kernel-Versionen und anschließende Neustarts zuverlässig beheben ließen.
Was ist passiert?
Januscape (CVE-2026-53359) ist ein Use-after-free-Fehler in der Speicherverwaltung der Virtualisierungslösung KVM. Er tritt bei verschachtelter Virtualisierung auf, wenn ein virtueller Server selbst eine weitere virtuelle Maschine ausführt. Das Hostsystem muss dann deren Speicherzuordnung nachbilden. Durch eine unvollständige Prüfung kann KVM dabei eine Speicherseite für den falschen Zweck wiederverwenden und freigeben, obwohl noch ein Verweis auf sie besteht. Ein Angreifer mit Root-Rechten im virtuellen Server kann diesen Fehler allein durch Vorgänge innerhalb seiner Maschine auslösen, Speicher des Host-Kernels beschädigen und damit die Trennung zwischen virtuellem Server und Host überwinden.
GhostLock (CVE-2026-43499) ist ebenfalls ein Use-after-free-Fehler. Er betrifft das Zusammenspiel von Futex und rtmutex. Diese Kernel-Mechanismen koordinieren Prozesse und Threads, die auf gemeinsam genutzte Ressourcen warten. Bei einer seltenen Abfolge mehrerer Vorgänge bereinigt der Kernel den Zustand des falschen Threads. Dadurch bleibt ein Verweis auf einen Bereich des Kernel-Speichers zurück, obwohl dieser bereits wieder freigegeben wurde. Ein lokaler Benutzer kann den Fehler ohne besondere Rechte über gewöhnliche Thread-Systemaufrufe auslösen. Der ungültige Verweis lässt sich anschließend dazu verwenden, Kernel-Speicher zu verändern und den Programmablauf zu übernehmen. So kann ein Angreifer Root-Rechte und damit die vollständige Kontrolle über das System erlangen. Unter bestimmten Voraussetzungen ist auch ein Ausbruch aus einem Container möglich.
Warum ist die Kombination besonders kritisch?
Zusammen könnten die beiden Lücken eine Angriffskette bilden: GhostLock verschafft einem lokalen Benutzer Root-Rechte innerhalb eines virtuellen Servers, Januscape ermöglicht anschließend den Ausbruch auf das darunterliegende Hostsystem.
Für GhostLock ist bereits ein funktionsfähiger öffentlicher Exploit verfügbar. Zu Januscape wurde bisher nur ein Proof of Concept veröffentlicht, der das Hostsystem zum Absturz bringen kann. Der Entdecker gibt allerdings an, auch über einen vollständigen VM-Escape-Exploit zu verfügen. Diesen hat er aus Sicherheitsgründen nicht veröffentlicht. Aufgrund des hohen Risikos haben wir unmittelbar reagiert.
Warum waren Neustarts erforderlich?
GhostLock und Januscape ließen sich nicht ohne Neustarts vollständig beheben. Die Korrekturen sind Bestandteil neuer Kernel-Versionen, die erst nach einem Neustart aktiv werden. Deshalb mussten wir die virtuellen Kundensysteme und die zugehörigen Hostsysteme neu starten. Laufende Dienste und Programme wurden dabei jeweils kurz unterbrochen.
Was bedeutet das für unsere Kunden?
Bei Webhosting-Paketen und Managed Servern hat unser Backup-System alle E-Mails zwischengespeichert, die während eines Neustarts eingingen. Nach dem Neustart wurden sie automatisch zugestellt. Es gingen keine E-Mails verloren.
Bei der Planung der Neustarts für dedizierte Server haben wir feste Nutzungszeiten und individuelle Absprachen nach Möglichkeit berücksichtigt.
Kunden mit besonderen Update- oder Wartungsvereinbarungen wurden zusätzlich direkt kontaktiert.
Wie KI die Suche nach Schwachstellen verändert
Sieben kritische Sicherheitslücken innerhalb weniger Monate sind eine ungewöhnliche Häufung. Ein Grund dafür ist die schnelle Weiterentwicklung KI-gestützter Analysewerkzeuge. Sie können große Mengen Programmcode schneller und systematischer untersuchen. Dadurch werden heute auch Fehler entdeckt, die viele Jahre unbemerkt geblieben sind.
Gleichzeitig kann KI auch die Entwicklung praxistauglicher Angriffsmethoden beschleunigen, sobald technische Details veröffentlicht werden. Wir gehen deshalb davon aus, dass in nächster Zeit weitere, möglicherweise sehr kritische Schwachstellen im Linux-Kernel entdeckt werden.
Für unsere Kunden ist diese Entwicklung dennoch kein Grund zur Sorge. Unsere Infrastruktur ist mehrstufig abgesichert: Viele Dienste laufen voneinander getrennt und virtualisiert, unsere Systeme werden kontinuierlich überwacht und wichtige Daten regelmäßig gesichert. Dadurch können wir Angriffswege begrenzen, Auffälligkeiten früh erkennen und Daten im Ernstfall wiederherstellen.
Zusätzlich verfolgen wir Sicherheitsmeldungen kontinuierlich und halten die von uns betreuten Kundensysteme auf dem aktuellen Sicherheitsstand. Wo es sicher möglich ist, setzen wir Schutzmaßnahmen ohne Neustart ein. Erfordert eine kritische Sicherheitslücke jedoch einen neuen Kernel, kündigen wir notwendige Neustarts so früh wie möglich an.