Eine Use-after-free im Linux-Kernel ist 15 Jahre lang unentdeckt geblieben und macht aus einem gewöhnlichen Nutzerkonto in Sekunden einen Administrator. Die Lücke trifft nahezu jede Distribution, die seit 2011 ausgeliefert wurde, und lässt sich sogar aus einem Container heraus ausnutzen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Rund fünf Sekunden nach dem Start des Exploits ist aus einem unprivilegierten Konto ein Root-Zugang geworden. GhostLock (CVE-2026-43499) heißt die Linux-Kernel-Lücke, die das Sicherheitslabor Nebula Security offengelegt hat[1]. Der Fehler steckt seit Mai 2011 im Code und betrifft praktisch jeden Server, jeden Desktop und jeden Container mit einem verwundbaren Kernel.
Das Wichtigste in Kürze
- GhostLock (CVE-2026-43499) ist eine Stack-Use-after-free im Sperrmechanismus des Linux-Kernels, eingeführt 2011.
- Ein lokaler Nutzer ohne Sonderrechte wird damit zu Root und bricht aus Containern aus, in Tests zu 97 % zuverlässig.
- Betroffen sind alle Kernel von 2.6.39 bis kurz vor 7.1, also nahezu jede große Distribution.
- Patches stehen bereit; Google hat dem Team rund 80.000 Euro über sein kernelCTF-Programm gezahlt.
Was steckt technisch hinter GhostLock?
GhostLock ist ein Fehler im rtmutex-Code des Kernels: Eine Aufräumfunktion räumt beim Futex-Requeue den falschen Thread ab und hinterlässt einen Zeiger auf bereits freigegebenen Stack-Speicher. Dieser Dangling Pointer ist die Grundlage der Rechteausweitung.
Der Kern liegt in der Funktion remove_waiter(), die ursprünglich für einen einzelnen Thread gedacht war. Über die Futex-Operationen mit Prioritätsvererbung wird sie jedoch im Namen eines anderen, schlafenden Threads aufgerufen.
Erzwingt ein Angreifer über einen konstruierten Deadlock einen Abbruch, löscht der Kernel die Sperr-Information des gerade laufenden statt des schlafenden Threads. Kehrt dieser später aus dem Kernel zurück, wird sein Stack-Speicher freigegeben, der Zeiger darauf bleibt aber bestehen.
Wie wird aus einem Futex-Fehler ein Root-Zugang?
Nebula füllt den freigegebenen Speicher gezielt mit einer gefälschten Kernel-Struktur, erzwingt darüber einen kontrollierten Schreibzugriff und überschreibt eine Netzwerk-Funktionstabelle. In rund fünf Sekunden und mit 97 % Erfolgsquote entsteht daraus Root, auch aus einem Container heraus.
Der entscheidende Trick besteht darin, den freigegebenen Stack-Speicher über einen Systemaufruf gezielt mit Nutzerdaten zu überschreiben. So entsteht eine gefälschte Sperr-Struktur, die dem Kernel einen einzigen, eng kontrollierten Schreibzugriff abringt.
Besonders brisant wird die Lücke in Kombination mit einem Browser-Fehler. Verkettet mit einer Schwachstelle in Firefox (CVE-2026-10702) reicht der Aufruf einer präparierten Website, um vom Browser bis zu Root-Rechten durchzugreifen. In der Diskussion auf Hacker News wird zudem berichtet, dass Testläufe auf Android-Geräten Boot-Schleifen ausgelöst haben, ein Hinweis darauf, wie tief der Fehler im System sitzt.
Eine Linux-Kernel-Lücke, die 15 Jahre lang niemand bemerkte
Warum GhostLock kein Einzelfall ist
Lang schlummernde Kernel-Lücken sind ein Muster, kein Ausreißer. Dirty COW hat jahrelang im Code geschlummert, Dirty Pipe hat jeden neueren Kernel getroffen, und erst vor Kurzem hat die Lücke Januscape 16 Jahre lang den Ausbruch aus der Virtualisierung erlaubt. GhostLock reiht sich hier nahtlos ein.
Das Problem ist nicht die einzelne Zeile Code, sondern die Halbwertszeit solcher Fehler. Ein Bug, der 2011 unbemerkt eingebaut wurde, wandert über Jahre in Milliarden Installationen, von der Cloud bis zum Router.
Wie schnell aus einer alten Zeile ein Vollzugriff wird, hat zuletzt die Kernel-Lücke Januscape gezeigt, die 16 Jahre unentdeckt einen Ausbruch aus KVM erlaubte. Auch abseits des Kernels häuft sich das Muster, etwa als vorinstallierte Software wie das MSI Center unbeabsichtigt System-Rechte vergeben hat oder zuletzt, als sich schwere Sicherheitslücken rund um KI-Modell-Releases gehäuft haben.
Nicht die Zahl der Lücken ist das Problem, sondern ihre Halbwertszeit. Ein Fehler von 2011, der heute in Sekunden Root liefert, zeigt: Patch-Management ist kein Projekt, sondern Dauerbetrieb.
— Markus Seyfferth, Chefredakteur Dr. Web
Was IT-Verantwortliche im DACH-Raum jetzt tun sollten
Kernel patchen und die Systeme neu starten, denn ohne Reboot bleibt der alte Kernel aktiv. Besonders dringlich ist das für Shared-Hosting, Multi-Tenant-Cloud und Container-Plattformen, wo ein einziges Nutzerkonto sonst die ganze Maschine übernimmt.
Die größten deutschen Hoster und Cloud-Anbieter teilen sich einen Kernel über viele Kunden hinweg. Genau dort verwandelt GhostLock einen harmlosen Mietaccount in einen Vollzugriff auf fremde Daten. Betreiber, die unter NIS2 fallen, müssen ohnehin nachweisen können, dass sie Sicherheitsupdates zeitnah einspielen.
Konkret sind jetzt mehrere Schritte gefragt: die Kernel-Version prüfen und die vom BSI und den Distributionen bereitgestellten Updates einspielen, jede gepatchte Maschine tatsächlich neu starten und Container-Images mit veraltetem Basis-Kernel neu bauen. Einen praktischen Einstieg dazu bietet unser Überblick, was ein Threat Model für kleine und mittlere Unternehmen ausmacht.
Quelle
[1] Nebula Security: „IonStack part II: GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years“ ↩
Mehr Newshunger?
- 16 Jahre unentdeckt: Sicherheitslücke „Januscape“ im Linux-Kernel
- Tenda-Firmware enthält eine versteckte Authentifizierungs-Hintertür
- Wie das vorinstallierte „MSI Center“ System-Rechte vergibt
- Fünf neue Prompt-Injection-Angriffe auf KI-Agenten
- Erst zwei Opfer, dann die Deutsche Bank: die Erpressergruppe UnSafe
- IT-Sicherheit für KMU: Was ein Threat Model ausmacht
