Docker Desktop CVE: Privilege-Escalation-Lücke unter Linux absichern

Eine neue Privilege-Escalation-Lücke in Docker Desktop bringt ausgerechnet die Linux-Variante in Bedrängnis – und zeigt, wie brüchig die vermeintlich saubere Trennung zwischen Container und Host in der Praxis sein kann. Wer auf seinem Entwickler-Rechner oder im Homelab mit Docker Desktop arbeitet, sollte jetzt patchen, statt abzuwarten.

Docker Desktop gilt unter Linux-Nutzern ohnehin als Kompromiss: Wer nur die Docker Engine braucht, installiert die eigentlich nicht, sondern greift zum nativen dockerd. Trotzdem läuft Docker Desktop mittlerweile auch unter Linux in nennenswerter Zahl, etwa auf Workstations mit gemischten Windows/Linux-Teams oder wenn die grafische Oberfläche für Onboarding-Zwecke gewünscht ist. Genau diese Linux-Installationen sind jetzt Teil einer aktuellen CVE-Meldung, die Privilege Escalation bis hinauf zum Host ermöglicht. Das ist kein theoretisches Szenario aus einem Whitepaper, sondern eine Schwachstelle mit klarer technischer Beschreibung, betroffenen Versionsbereichen und einem Fix, der bereits ausgerollt wurde.

Die aktuelle Lücke: grpcfuse-Kernelmodul unter Beschuss

Im Zentrum steht eine Schwachstelle im grpcfuse-Kernelmodul, das in der Linux-VM von Docker Desktop für die Dateisystem-Kommunikation zuständig ist. Es handelt sich um eine Out-of-Bounds-Read-Schwäche: Ein lokaler Angreifer kann durch gezielte Schreibzugriffe auf /proc/docker-Einträge die Speichergrenzen des Moduls überschreiten und dadurch seine Rechte erhöhen. Der genaue Umfang der möglichen Rechteausweitung ist in der offiziellen Beschreibung als „unspecified“ klassifiziert, die Einordnung als Privilege-Escalation-Schwachstelle ist aber eindeutig.

Betroffen sind laut der Analyse von SentinelOne Docker Desktop-Installationen bis einschließlich Version 4.61.0 – und das ausdrücklich auf allen drei Plattformen: Windows, macOS und Linux. Der Fix kam mit Docker Desktop 4.62.0. Wer also noch auf einer älteren Version arbeitet, sollte das Update nicht auf die lange Bank schieben. Gerade weil der Angriffsweg lokal ist, unterschätzen viele Admins das Risiko – ein Denkfehler, den man sich in der Container-Sicherheit nicht leisten kann, denn „lokal“ heißt in Multi-User-Umgebungen oder auf CI-Runnern eben nicht „harmlos“.

Warum Linux-Systeme hier keine Ausnahme sind

Ein verbreiteter Irrglaube lautet: Docker Desktop sei im Kern ein Windows/macOS-Produkt, weil es dort die Docker Engine über eine Linux-VM bereitstellt – unter Linux laufe ohnehin alles nativer und damit sicherer. Diese Annahme trägt hier nicht. Auch die Linux-Version von Docker Desktop kapselt Teile der Funktionalität in einer eigenen VM-Schicht, um eine konsistente Erfahrung über alle Betriebssysteme zu bieten. Genau diese Abstraktionsschicht war der Ort der Schwachstelle. Wer Docker Desktop unter Linux installiert hat, weil die grafische Oberfläche praktisch ist, handelt sich damit potenziell dieselben Angriffsflächen ein wie Windows-Nutzer – nur eben zusätzlich zu den nativen Kernel-Mechanismen, auf die man sich unter Linux eigentlich verlassen möchte.

Das ist meiner Einschätzung nach der eigentliche Knackpunkt bei Docker Desktop: Die Software verspricht plattformübergreifende Konsistenz, kauft sich diese aber mit einer zusätzlichen Virtualisierungsebene, die eigene Bugs mitbringt. Wer unter Linux „nur mal eben“ Container starten will, bekommt mit Docker Desktop mehr bewegliche Teile als mit der nativen Engine – und mehr bewegliche Teile bedeuten mehr potenzielle CVE-Kandidaten. Das Muster ähnelt strukturell anderen Fällen, in denen privilegierte Fernzugriffs- und Verwaltungslösungen zur Angriffsfläche wurden, wie etwa bei der Sicherheitslücke in BeyondTrust Privileged Remote Access, wo ebenfalls eine zusätzliche Verwaltungsschicht zum Einfallstor wurde, obwohl sie eigentlich für mehr Sicherheit sorgen sollte.

Kein Einzelfall: CVE-2025-9074 und die exponierte Engine-API

Die aktuelle grpcfuse-Lücke reiht sich in eine Serie ähnlich gelagerter Probleme ein. Besonders relevant ist CVE-2025-9074, eine als kritisch eingestufte Schwachstelle (CVSS 9,3) in Docker Desktop, bei der lokal laufende Linux-Container über das interne Docker-Subnetz auf die Docker Engine API zugreifen konnten – und das unabhängig davon, ob Enhanced Container Isolation aktiviert war oder nicht. Aus einem Container heraus ließen sich damit privilegierte Docker-API-Befehle ausführen: andere Container manipulieren, Images ziehen, Volumes mounten. In bestimmten Konfigurationen konnte sogar das Host-Laufwerk mit den Rechten des Desktop-Benutzers eingebunden werden. Details dazu listet der NVD-Eintrag zu CVE-2025-9074 auf.

Der Fix kam mit Docker Desktop 4.44.3, das Zugriffskontrollen auf den internen API-Endpunkt einführte. Bemerkenswert ist, dass „Enhanced Container Isolation“ – das eigentliche Sicherheitsversprechen von Docker Desktop für genau solche Szenarien – die Lücke nicht verhindert hat. Das relativiert ein verbreitetes Argument in Verkaufsgesprächen und Dokumentationen: Isolation-Features sind kein Ersatz für saubere Netzwerksegmentierung und Authentifizierung auf API-Ebene, sie sind eine zusätzliche Schicht, keine Garantie.

BSI-Warnung und der Blick auf CVE-2025-10657

Auch das Bundesamt für Sicherheit in der Informationstechnik hat sich zu Docker Desktop positioniert. Ende September 2025 meldete das BSI eine Warnung zu Version 4.46.0 mit dem Hinweis auf eine Privilege-Escalation-Schwachstelle, katalogisiert als CVE-2025-10657. Betroffen waren laut Meldung Linux-, UNIX- und Windows-Systeme. Die Risikobewertung fiel mit einem CVSS Base Score von 7,5 in den mittleren bis oberen Bereich, das BSI selbst stufte das Risiko intern auf Stufe 5 (mittel) ein. Auch hier gilt: lokaler Angreifer, kein Remote-Zugriff nötig – aber genau diese lokalen Szenarien sind in geteilten Build-Umgebungen, auf Jump-Hosts oder in Schulungs-VMs alles andere als exotisch.

Parallel dazu zeigt ein älterer Fall aus dem Docker-Engine-Umfeld, dass Patches nicht immer halten, was sie versprechen: Bei CVE-2024-41110 handelte es sich um eine Regression einer bereits behobenen Rechteausweitungs-Lücke, die in Docker-Engine-Versionen zwischen 19.03.15 und 27.1.0 wieder auftauchte. Der Fix wurde erst ab Version 23.0.14 nachgezogen. Wer glaubt, ein einmal gepatchtes System bleibe automatisch dauerhaft sicher, irrt – Regressions sind in komplexen Codebasen wie Docker keine Seltenheit. Wer sich generell mit der Frage beschäftigt, ob ein Wechsel der Plattform oder Distribution sinnvoller ist als das ständige Nachziehen von Patches auf einem gewachsenen System, findet dazu Einordnung in unserem Beitrag zum Wechsel zwischen Windows- und Linux-Distributionen auf dem Desktop, der die grundsätzliche Abwägung zwischen Komfort und Kontrolle beleuchtet.

Patch-Status: Welche Version jetzt Pflicht ist

Für die Praxis lässt sich die Lage so zusammenfassen: Wer Docker Desktop unter Linux betreibt, sollte mindestens auf Version 4.62.0 aktualisieren, um gegen die grpcfuse-Schwachstelle abgesichert zu sein. Ältere CVEs wie CVE-2025-9074 sind seit 4.44.3 behoben, CVE-2025-10657 betrifft konkret Version 4.46.0 und sollte mit jedem späteren Release erledigt sein. Wichtig ist der Blick in die offiziellen Docker Security Announcements, denn Versionsnummern in Drittanbieter-Feeds veralten schnell und decken oft nur einzelne CVEs ab, nicht den Gesamtstatus einer Installation.

Ein pragmatischer Check in drei Schritten: Docker Desktop-Version über die GUI oder docker version im Terminal auslesen, gegen die aktuelle Release-Liste abgleichen, bei Zweifel sofort aktualisieren. Wer automatisierte Updates deaktiviert hat, weil das früher mal einen Build-Prozess durcheinandergebracht hat, sollte diese Entscheidung bei sicherheitsrelevanten Patches noch einmal überdenken. Docker Desktop ist kein Server-Betriebssystem mit Long-Term-Support-Zyklen – hier zählt der aktuelle Patch-Stand, nicht die Stabilität einer bestimmten Minor-Version.

Praxisszenario: Was ein erfolgreicher Angriff bedeuten würde

Um die Tragweite greifbar zu machen, hilft ein einfaches Gedankenexperiment. Stellen Sie sich einen Entwickler-Laptop vor, auf dem mehrere Projekte parallel in Containern laufen – ein Test-Setup für einen Kunden, ein internes CI-Skript, vielleicht ein Debugging-Container mit erweiterten Rechten, der „nur kurz“ für einen Test gestartet und dann vergessen wurde. Gelingt es einem Angreifer, über eine der beschriebenen Lücken aus einem dieser Container auszubrechen, landet er nicht in einer isolierten Sandbox, sondern potenziell im Kontext des Host-Nutzers oder sogar mit Root-Rechten auf dem gesamten System. Von dort aus sind SSH-Keys, gespeicherte Zugangsdaten, Quellcode und unter Umständen auch Zugriffe auf interne Netzwerke erreichbar.

Besonders kritisch wird es in geteilten Umgebungen: CI/CD-Runner, auf denen mehrere Teams oder sogar mehrere Kunden Build-Jobs ausführen, sind ein klassisches Ziel für genau diese Art von Schwachstellen, weil der „lokale Angreifer“ hier nicht der Laptop-Besitzer selbst sein muss, sondern ein manipulierter Build-Schritt, ein kompromittiertes Dependency-Paket oder ein bösartiger Pull Request aus einem Fork-Repository. Wer in einer solchen Umgebung Docker Desktop statt einer gehärteten, dedizierten Container-Runtime einsetzt, vergrößert die Angriffsfläche in einem Bereich, der ohnehin schon zu den sensibelsten der gesamten Softwarelieferkette zählt. Genau deshalb raten Sicherheitsteams in Unternehmen zunehmend dazu, Build-Infrastruktur strikt von Entwickler-Arbeitsplätzen zu trennen und auf Runner-Ebene grundsätzlich rootless oder in dedizierten, minimal ausgestatteten VMs zu arbeiten.

Rootless Mode: Isolation, die den Namen verdient

Die naheliegendste Gegenmaßnahme für alle, die nicht auf Docker Desktop verzichten wollen oder können, ist der Rootless Mode der Docker Engine. Dabei läuft der Daemon nicht mit Root-Rechten, sondern im Kontext eines normalen Nutzers, unterstützt durch User-Namespaces. Das reduziert den Schaden im Fall einer erfolgreichen Rechteausweitung erheblich: Ein Angreifer, der aus einem Container ausbricht, landet nicht automatisch im Root-Kontext des Hosts, sondern bleibt im eingeschränkten Namespace des jeweiligen Benutzers gefangen.

Der Rootless Mode ist unter nativer Docker Engine seit einigen Jahren produktionsreif, bei Docker Desktop ist die Integration je nach Plattform unterschiedlich weit fortgeschritten. Wer unter Linux ohnehin näher an der nativen Engine arbeitet, hat hier den einfacheren Weg. Die Einrichtung kostet ein paar Handgriffe mehr als die Standardinstallation, aber wer schon einmal einen Privilege-Escalation-Vorfall aufräumen musste, empfindet diesen Mehraufwand als vernachlässigbar. Zusätzlich gehört zur Grundhärtung, dass Container grundsätzlich als nicht-Root-Nutzer laufen, keine --privileged-Flags gesetzt werden und überflüssige Linux-Capabilities konsequent entfernt werden. Die Option --security-opt=no-new-privileges sollte in jedem Compose-File und jedem Run-Kommando Standard sein, nicht Ausnahme.

Podman als echte Alternative zum Daemon-Modell

Wer die wiederkehrenden Docker-Desktop-CVEs als strukturelles Problem begreift und nicht nur als Serie einzelner Bugs, landet fast zwangsläufig bei Podman. Der grundlegende Unterschied: Podman kommt ohne dauerhaft laufenden Root-Daemon aus, Container werden direkt als Kindprozesse des jeweiligen Nutzers gestartet. Es gibt schlicht keine zentrale Angriffsfläche wie den Docker-Daemon, über dessen API sich Rechte ausweiten lassen. Das Fehlen dieser Komponente entfernt eine ganze Klasse von Schwachstellen, zu der auch die aktuelle grpcfuse-Lücke und CVE-2025-9074 gehören.

Das ist keine Ideologie, sondern eine nachvollziehbare Architekturentscheidung – und genau deshalb ist Podman für mich mehr als nur ein Lippenbekenntnis zu Open Source, sondern die pragmatischere Wahl für Linux-Server und Homelab-Umgebungen. Docker-kompatible Kommandozeile, Unterstützung für Compose-Dateien über Zusatztools, Integration in systemd über Quadlets – der Umstieg ist für die meisten Standard-Workflows machbar, ohne dass man sein gesamtes Deployment neu schreiben muss. Wer unter Linux zusätzlich auf eine grafische Oberfläche verzichten kann, spart sich mit Podman nicht nur eine potenzielle CVE-Quelle, sondern auch eine ganze VM-Abstraktionsschicht, die auf Linux-Hosts ohnehin überflüssig ist.

Gegenargumente: Warum viele trotzdem bei Docker Desktop bleiben

So klar die sicherheitstechnische Argumentation für Podman oder den Rootless-Betrieb auch ist, in der Praxis bleibt Docker Desktop für viele Teams die realistischere Wahl – und das aus nachvollziehbaren Gründen. Die grafische Oberfläche erleichtert das Onboarding neuer Mitarbeiter erheblich, gerade in Teams, in denen nicht jeder täglich mit der Kommandozeile arbeitet. Funktionen wie integrierte Kubernetes-Cluster per Klick, Dev-Environments oder die zentrale Ressourcenverwaltung über die Desktop-Oberfläche sparen im Alltag Zeit, die man sonst in Dokumentation und Schulung investieren müsste. Auch die einheitliche Bedienung über Windows, macOS und Linux hinweg ist für Firmen mit gemischten Geräteflotten ein handfester organisatorischer Vorteil, den man nicht kleinreden sollte.

Hinzu kommt: Nicht jede Schwachstelle betrifft jede Konfiguration gleich stark. Wer Docker Desktop ausschließlich auf einem isolierten Einzelplatzrechner ohne sensible Zugangsdaten nutzt und keine fremden Images aus unbekannten Quellen ausführt, trägt ein spürbar geringeres Risiko als ein CI-Runner mit Zugriff auf Produktionsgeheimnisse. Die Empfehlung, sofort auf Podman zu wechseln, ist deshalb kein Automatismus, sondern eine Abwägung, die von Nutzungskontext, Team-Know-how und vorhandener Infrastruktur abhängt. Wer diese Abwägung bewusst trifft und dokumentiert, statt sie zu ignorieren, handelt bereits deutlich verantwortungsvoller als der Durchschnitt.

Härtungs-Checkliste für Admins und Selfhoster

Für alle, die kurzfristig handeln müssen, bevor die grundsätzliche Docker-versus-Podman-Frage geklärt ist, hilft eine kompakte Liste konkreter Schritte. Docker Desktop auf mindestens Version 4.62.0 aktualisieren, danach regelmäßig die Security Announcements prüfen. Container niemals mit --privileged starten, wenn es nicht zwingend nötig ist – und in den meisten Fällen ist es das nicht. Nicht benötigte Capabilities per --cap-drop=ALL entfernen und nur explizit benötigte wieder hinzufügen. Den Docker-Daemon niemals ungeschützt über TCP exponieren, weder lokal noch im Netzwerk, ohne TLS und Authentifizierung dazwischenzuschalten.

Für Entwickler-Teams mit gemeinsam genutzten Build-Servern lohnt sich zusätzlich ein Blick auf CVE-Scanner, die Container-Images und laufende Instanzen automatisiert gegen bekannte Schwachstellendatenbanken abgleichen – so lassen sich veraltete Basis-Images oder ungepatchte Docker-Versionen frühzeitig erkennen, bevor ein Audit oder ein Vorfall sie ans Licht bringt. Wer sensible Zugangsdaten in Containern verwaltet, etwa über Tools wie Bitwarden-Integrationen für CI-Pipelines, sollte diese Geheimnisse ohnehin nie direkt im Image, sondern über separate Secret-Stores einbinden – eine Privilege-Escalation-Lücke im Docker-Stack macht sonst aus einem lokalen Zugriffsproblem sofort ein Datenleck.

Sinnvoll ist außerdem, Basis-Images regelmäßig neu zu bauen statt sie über Monate unverändert weiterlaufen zu lassen, da sich Sicherheitspatches der zugrunde liegenden Distribution sonst nicht in laufenden Containern niederschlagen. Ergänzend hilft ein einfaches, aber oft vernachlässigtes Prinzip: Wer Container von unbekannten Quellen zieht, sollte grundsätzlich signierte Images bevorzugen und Registries auf vertrauenswürdige Herkunft prüfen, statt jedes gefundene Image ungeprüft auszuführen. Diese Disziplin kostet im Alltag kaum Zeit, verringert aber die Wahrscheinlichkeit, überhaupt erst einen bösartigen Container zu starten, der eine Lücke wie die aktuelle grpcfuse-Schwachstelle ausnutzen könnte.

Wichtig ist auch die organisatorische Seite: Wer verwaltet in Ihrem Team die Docker-Desktop-Installationen, und wer erhält Alerts, wenn ein neues Security Advisory erscheint? Ohne klare Verantwortlichkeit bleibt jede noch so gute Checkliste graue Theorie. Ein einfacher, aber wirksamer Schritt ist ein automatisierter Cronjob oder eine CI-Stufe, die die installierte Docker-Version gegen die aktuelle Release-Liste abgleicht und bei Abweichung eine Warnung auslöst. In größeren Teams empfiehlt sich zusätzlich eine kurze, regelmäßige Routine – etwa einmal im Monat –, in der jemand explizit prüft, ob neue Docker- oder Container-Runtime-CVEs veröffentlicht wurden, statt sich ausschließlich auf zufällige Nachrichtenfunde zu verlassen.

Was bleibt von dieser Lücke?

Docker Desktop bleibt ein Komfortprodukt mit wiederkehrenden Sicherheitsproblemen, die aus seiner eigenen Architektur resultieren – der Versuch, drei sehr unterschiedliche Betriebssysteme unter einer gemeinsamen VM-Schicht zu vereinheitlichen, produziert offenbar zuverlässig neue Angriffsflächen. Die aktuelle grpcfuse-Schwachstelle ist gepatcht, die nächste CVE kommt mit ziemlicher Sicherheit trotzdem. Für Linux-Nutzer, die sich diese zusätzliche Abstraktionsschicht eigentlich sparen könnten, ist die eigentliche Frage nicht, wie oft man noch patchen will, sondern ob man den Daemon überhaupt braucht. Wer den nativen Weg über Rootless-Betrieb oder Podman geht, tauscht ein Stück Komfort gegen deutlich weniger Angriffsfläche – ein Deal, der sich in der Praxis meistens auszahlt. Wer hingegen aus guten organisatorischen Gründen bei Docker Desktop bleibt, sollte diese Entscheidung zumindest mit konsequentem Patch-Management, minimalen Rechten und klarer Verantwortlichkeit absichern, statt sich allein auf das nächste Update zu verlassen.