GhostLock: 15 Jahre alte Linux-Kernel-Lücke – Exploit ist öffentlich

Im Linux-Kernel steckt seit rund 15 Jahren eine Schwachstelle, über die ein lokaler Nutzer volle Root-Rechte erlangen und aus Containern auf den Host ausbrechen kann. Die Lücke CVE-2026-43499 – von den Entdeckern „GhostLock“ getauft – wird mit einem CVSS-Wert von 7.8 als hoch eingestuft. Bestätigte Angriffe gibt es bislang nicht, doch seit Anfang Juli kursiert funktionierender Exploit-Code, der laut Forschern zu 97 % zuverlässig arbeitet – deshalb zählt jetzt jeder Tag bis zum Kernel-Update.

Was ist passiert?

Sicherheitsforscher von Nebula Security haben eine Use-after-Free-Schwachstelle im Locking-Code des Linux-Kernels offengelegt. Der Fehler steckt im Zusammenspiel von futex und der Real-Time-Mutex-Logik (rt_mutex) bei der sogenannten Priority Inheritance: Der Kernel räumt in einem Fehlerpfad die falsche Task auf und hinterlässt einen ungültigen Speicherzustand. Diesen können Angreifer zu einer zuverlässigen Rechteausweitung ausbauen.

Das Problem ist nach Angaben der Forscher seit Kernel 2.6.39 (2011) enthalten. Für die Ausnutzung sind weder Sonderrechte noch Netzwerkzugriff nötig – normale Threading-Aufrufe eines beliebigen lokalen Programms genügen. Besonders brisant: Dieselbe Lücke erlaubt einen Container-Ausbruch, ein kompromittierter Container kann also auf den Host-Kernel durchgreifen. Die Entdecker haben funktionierenden Exploit-Code veröffentlicht; eine aktive Ausnutzung in freier Wildbahn ist bisher nicht bestätigt.

Wer ist betroffen?

Betroffen ist praktisch jede gängige Linux-Distribution – der futex-Mechanismus ist ein Kernbaustein, den nahezu jede Multithreading-Anwendung nutzt. Das reicht von Servern und Cloud-Instanzen über Container-Hosts (Docker, Kubernetes) und CI-Runner bis zu NAS- und Appliance-Systemen mit Linux-Kernel. Wo mehrere Nutzerkonten oder Container auf einem System laufen, ist das Risiko am größten.

Der Patch-Stand ist uneinheitlich: Debian und SUSE haben ihre unterstützten Kernel-Linien bereits korrigiert, Ubuntu hat den Fix im Hauptkernel für 26.04 LTS eingespielt – mehrere ältere LTS-Versionen sind jedoch noch verwundbar oder warten auf ein Update. Oracle Linux hat UEK-Fixes für die Versionen 9 und 10 veröffentlicht, bei AlmaLinux, Amazon Linux und Red Hat ist die Verteilung teils noch im Gang. Eine kürzlich installierte Kernel-Aktualisierung ist daher kein Garant für Schutz.

Was jetzt zu tun ist

1. Kernel aktualisieren: Spielen Sie die aktuellsten Kernel-Pakete Ihrer Distribution ein und starten Sie das System neu – ein Update wirkt erst nach dem Reboot in den neuen Kernel.
2. Version gegenprüfen: Vergleichen Sie den laufenden Kernel (uname -r) mit der als behoben gelisteten Version im Security-Tracker Ihrer Distribution, statt sich auf das reine Update-Datum zu verlassen.
3. Container-Hosts priorisieren: Docker- und Kubernetes-Knoten sowie Multi-Tenant- und CI-Systeme zuerst patchen – hier wiegt der Container-Ausbruch besonders schwer.
4. Zwischenlösung, wo kein Patch verfügbar ist: Lokalen Shell-Zugang auf vertrauenswürdige Nutzer beschränken und in Container-Umgebungen per seccomp-Profil die auslösenden futex-Operationen einschränken. Das erschwert Angriffe, ersetzt aber kein Kernel-Update.
5. Beobachten: Kernel-Logs auf Hinweise auf Rechteausweitungen prüfen und das Monitoring bis zum flächendeckenden Patch verschärfen.

So hilft Binary System Services

Der Kern des Problems ist Übersicht: Welche Systeme laufen mit welchem Kernel, welche sind bereits gepatcht und welche warten noch? Wir inventarisieren Ihren Server- und Container-Bestand, priorisieren die verwundbaren Systeme und spielen Kernel-Updates kontrolliert samt geplanter Neustart-Fenster ein – inklusive anschließender Verifikation und Monitoring. So schließen Sie die Lücke, bevor der öffentliche Exploit den Weg in Angreifer-Werkzeuge findet. Sprechen Sie uns an.

Angaben ohne Gewähr. Im Zweifel bitte die offizielle Quelle prüfen.