Docker Model Runner CVE-2026-28400: Docker Desktop jetzt auf 4.61.0 prüfen
Eine Schwachstelle im Docker Model Runner erlaubt unauthentifizierte Zugriffe auf die Konfigurations-API und darüber Schreibzugriff auf Dateien des Prozesses. Docker Desktop ab Version 4.61.0 enthält den Fix, Admins sollten die Version jetzt prüfen.
Eine als hoch eingestufte Schwachstelle im Docker Model Runner betrifft alle Docker-Desktop-Installationen, bei denen die Funktion aktiviert ist. Betroffen sind Versionen des Model Runners vor 1.0.16, gefixt wurde die Lücke in Version 1.0.16. Wer Docker Desktop seit Version 4.46.0 im Einsatz hat, sollte prüfen, ob Model Runner aktiv ist, denn ab dieser Version war die Funktion standardmäßig eingeschaltet.
Nicht betroffen sind Installationen, bei denen Model Runner nie aktiviert wurde, sowie reine Docker-Engine-Server-Umgebungen ohne Docker Desktop. Wer Docker Desktop 4.61.0 oder neuer einsetzt, hat den Fix bereits an Bord. Für alle anderen gilt heute Handlungsbedarf, denn die Lücke ist ohne Authentifizierung aus Standardcontainern erreichbar.
Was ist passiert?
Am Ursprung der Meldung steht das GitHub Security Advisory GHSA-m456-c56c-hh5c im Repository docker/model-runner. Der Model Runner stellt eine lokale API bereit, über die sich lokale Sprachmodelle in Docker Desktop verwalten und ausführen lassen. Der Endpunkt POST /engines/_configure nimmt dabei beliebige Runtime-Flags entgegen und reicht diese ohne Prüfung an die zugrunde liegende llama.cpp-Engine weiter.
Genau darin liegt das Problem. Wer den Endpunkt erreichen kann, kann Flags setzen, die llama.cpp normalerweise nur über vertrauenswürdige Konfiguration erhält. Ein Beispiel ist das Flag --log-file, mit dem sich Schreib- und Überschreibzugriff auf Dateien erreichen lässt, auf die der Model-Runner-Prozess zugreifen kann. Damit verlässt der Angriff die reine Model-Runner-Umgebung und betrifft potenziell den gesamten Datenbestand von Docker Desktop.
Wer ist betroffen?
Betroffen sind Docker-Desktop-Nutzer mit aktiviertem Model Runner in einer Version vor 1.0.16. Da Docker Desktop ab 4.46.0 die Funktion standardmäßig aktiviert hatte, zählen viele Installationen dazu, die Model Runner nie bewusst eingerichtet haben. Der Endpunkt ist aus Standardcontainern heraus erreichbar, und zwar über die interne Adresse model-runner.docker.internal, die Docker Desktop für den Zugriff auf lokale Modelle bereitstellt.
Das bedeutet konkret: Jeder Container, der im Standardnetzwerk läuft und Zugriff auf model-runner.docker.internal hat, kann die verwundbare API erreichen, ohne dass eine Authentifizierung nötig ist. Damit reicht bereits ein kompromittierter oder bösartiger Container im selben Docker-Desktop-Setup, um die Konfigurations-API anzusprechen. Nicht betroffen sind Umgebungen, in denen Model Runner deaktiviert wurde oder in denen kein Container auf die interne Model-Runner-Adresse zugreifen kann.
Wie kritisch ist das?
Der Hersteller bewertet die Schwachstelle mit einem CVSS-Wert von 7.5, also hoch. Die praktische Auswirkung hängt stark von der lokalen Konfiguration ab. Über das --log-file-Flag lässt sich im schlimmsten Fall die virtuelle Festplattendatei Docker.raw überschreiben, auf der Docker Desktop unter macOS und Linux-VM-Backends Container, Images, Volumes und Build-Historie speichert. Ein Überschreiben dieser Datei kann zum vollständigen Verlust aller lokalen Docker-Daten führen.
Ein Container Escape, also das Verlassen der Container-Isolation in Richtung Host-System, ist damit nicht pauschal verbunden. Ein solcher Ausbruch ist laut Advisory nur in speziellen Konfigurationen und mit zusätzlicher Nutzerinteraktion denkbar. Wer diese Bedingungen nicht erfüllt, muss also vor allem mit Datenverlust bei Docker.raw rechnen, nicht automatisch mit einer vollständigen Kompromittierung des Host-Systems.
| Aspekt | Bewertung laut Advisory |
|---|---|
| Betroffene Versionen | Docker Model Runner vor 1.0.16 |
| Gefixte Version | Docker Model Runner 1.0.16 |
| Docker Desktop mit Fix | Version 4.61.0 oder neuer |
| Angriffsvektor | POST /engines/_configure ohne Authentifizierung |
| Erreichbarkeit | Aus Standardcontainern über model-runner.docker.internal |
| Mögliche Folge | Überschreiben von Dateien, im schlimmsten Fall Docker.raw |
| Container Escape | Nur in speziellen Konfigurationen mit Nutzerinteraktion |
| CVSS-Bewertung | 7.5, hoch |
Was sollten Admins jetzt tun?
Der erste Schritt ist immer die Bestandsaufnahme. Erst wenn klar ist, welche Docker-Desktop-Version und welcher Model-Runner-Status im Einsatz sind, lässt sich die Dringlichkeit einschätzen.
- Aktuelle Docker-Desktop-Version im Programm unter Docker Desktop, Einstellungen, About prüfen.
- Prüfen, ob Model Runner unter Einstellungen im Bereich Features in Development oder Beta aktiviert ist.
- Docker Desktop auf Version 4.61.0 oder neuer aktualisieren, sofern noch nicht geschehen.
- Nach dem Update prüfen, ob Docker Model Runner automatisch auf Version 1.0.16 oder neuer angehoben wurde.
- Falls Model Runner aktuell nicht benötigt wird, die Funktion in den Einstellungen deaktivieren, um die Angriffsfläche zu reduzieren.
- Enhanced Container Isolation aktivieren, sofern noch nicht geschehen, um Zugriffe aus Containern zusätzlich einzuschränken.
- Berücksichtigen, dass Enhanced Container Isolation nicht in jedem Fall hilft, insbesondere bei bestimmter localhost-TCP-Exposition bleibt ein Restrisiko bestehen.
- Backups der relevanten Docker-Volumes und wichtiger Container-Konfigurationen vor größeren Updates anlegen, damit ein möglicher Datenverlust bei Docker.raw abgefedert werden kann.
- Die offiziellen Docker-Release-Notes auf weitere sicherheitsrelevante Änderungen im gleichen Update prüfen.
- Interne Dokumentation aktualisieren, welche Entwicklerrechner Docker Desktop mit Model Runner einsetzen, damit künftige Advisories schneller zugeordnet werden können.
Schritt für Schritt prüfen und aktualisieren
Für Admins, die mehrere Arbeitsplätze betreuen, empfiehlt sich ein einheitliches Vorgehen, damit keine Installation übersehen wird.
- Docker Desktop öffnen und im Menü oben rechts auf das Zahnrad-Symbol für Einstellungen klicken.
- Im Bereich About oder Software Updates die installierte Versionsnummer ablesen und mit 4.61.0 vergleichen.
- Ist die Version älter, über die integrierte Update-Funktion von Docker Desktop das Update anstoßen oder den aktuellen Installer von der offiziellen Docker-Webseite herunterladen.
- Nach dem Update Docker Desktop neu starten und die Versionsnummer erneut kontrollieren.
- Im Bereich Features in Development oder Beta prüfen, ob Model Runner aktiviert ist, und die dort angezeigte Model-Runner-Version notieren.
- Bei Unsicherheit über den Aktivierungsstatus die offiziellen Release-Notes und das Security-Advisory als Referenz heranziehen, um die eigene Konfiguration einzuordnen.
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen mit Entwicklerarbeitsplätzen ist diese Meldung vor allem deshalb relevant, weil Docker Desktop auf vielen Rechnern ohne zentrale Kontrolle läuft. Ein automatisch aktiviertes Feature wie Model Runner kann so unbemerkt zur Angriffsfläche werden, ohne dass ein Team es aktiv eingerichtet hat.
Der wirtschaftliche Schaden liegt weniger in einem klassischen Datendiebstahl als im möglichen Verlust lokaler Entwicklungsumgebungen, wenn Docker.raw beschädigt wird. Verlorene Container, Images und Build-Historie bedeuten für Entwicklerteams zusätzlichen Aufwand, um Umgebungen neu aufzusetzen. Wer regelmäßige Backups der Docker-Konfiguration und wichtiger Images pflegt, reduziert dieses Risiko unabhängig vom konkreten Advisory.
Passende Anleitungen auf S-EDV
- Docker sicher aktualisieren, Schritt für Schritt Anleitung, ein allgemeiner Leitfaden für den Umgang mit Docker-Sicherheitsupdates.
- Docker Compose absichern, Secrets, Healthchecks und Non-Root, für Teams, die ihre Compose-Setups zusätzlich härten wollen.
- Docker Images scannen mit Trivy, Schwachstellen und SBOM, um weitere Schwachstellen in eigenen Images frühzeitig zu erkennen.
