Docker Sandboxes: kritische Lücke erlaubt Zugriff auf macOS-Host-Dateien

Docker hat zwei Schwachstellen in Docker Sandboxes geschlossen, der Funktion, mit der Entwicklerinnen und Entwickler nicht vertrauenswürdigen Code und KI-Agenten in einer isolierten microVM ausführen. Die kritische Lücke CVE-2026-77179 erlaubt es Code, der in der Sandbox läuft, aus dem freigegebenen Projektverzeichnis auszubrechen und beliebige Dateien auf dem macOS-Host zu lesen und zu verändern. Betroffen sind die Sandboxes-Versionen 0.28.0 bis einschließlich 0.41.x auf macOS. Behoben ist das Problem in Docker Sandboxes 0.42.0, veröffentlicht am 7. September 2026.

Nicht betroffen sind reine Linux-Server mit Docker Engine ohne Docker Desktop und ohne die Sandboxes-Funktion. Auch wer Docker Desktop nutzt, die Sandboxes-Funktion aber nie eingeschaltet hat, ist von der kritischen Lücke nicht betroffen. Die zweite, als hoch eingestufte Lücke CVE-2026-79994 betrifft Versionen 0.37.0 bis vor 0.42.0 plattformübergreifend. Es handelt sich in beiden Fällen nicht um eine Lücke, die von außen aus dem Netz ausgelöst wird: Voraussetzung ist immer, dass jemand fremden oder nicht geprüften Code in der Sandbox startet. Genau das ist aber der Normalfall bei Entwicklerarbeitsplätzen, auf denen KI-Agenten oder fremde Repositories getestet werden. Handeln sollten daher alle, die Sandboxes auf einem Mac einsetzen, heute.

Was ist Docker Sandboxes überhaupt?

Docker Sandboxes ist eine vergleichsweise junge Funktion rund um Docker Desktop. Sie startet eine eigene, gekapselte Mikro-Virtualisierung mit eigenem Docker-Daemon und eigenem Dateisystem. Ziel ist es, Software auszuführen, der man nicht vollständig traut, ohne dabei den Arbeitsrechner zu gefährden.

Typische Einsatzfälle sind:

• KI-Coding-Agenten, die selbstständig Befehle ausführen, Pakete installieren und Dateien schreiben, ohne dass ein Mensch jeden Schritt bestätigt.
• Fremde Repositories aus GitHub oder von Kunden, die man testen oder bauen möchte, bevor man ihren Inhalt beurteilen kann.
• Build- und Testläufe mit vielen transitiven Abhängigkeiten aus öffentlichen Paketquellen.

Damit die Arbeit in der Sandbox überhaupt sinnvoll ist, wird in der Regel ein Projektverzeichnis vom Host in die Sandbox gespiegelt. Für diese Freigabe nutzt Docker auf macOS einen virtio-fs-Server auf Host-Seite. Genau dieser Server ist der Ort der kritischen Lücke. Das Sicherheitsversprechen der Sandbox lautet: Was in der Sandbox passiert, bleibt innerhalb des freigegebenen Verzeichnisses. Dieses Versprechen war verletzt.

Was ist passiert?

Laut der offiziellen Docker-Sicherheitsmeldung folgte der virtio-fs-Host-Server auf macOS beim erneuten Öffnen einer bereits gelöschten Datei dem gespeicherten Pfad und wertete dabei Symlinks aus. Ein bösartiger Gast konnte ein übergeordnetes Verzeichnis durch einen symbolischen Link ersetzen, nachdem der Pfad einmal aufgezeichnet worden war. Der spätere Dateizugriff landete dann außerhalb des freigegebenen Arbeitsverzeichnisses.

Die Folge: Code in der Sandbox konnte Dateien lesen und schreiben, auf die der Prozess des Virtual Machine Monitors, also das Benutzerkonto, unter dem die VM läuft, Zugriff hat. Weil sich über das Verändern sensibler Host-Dateien auch Codeausführung erreichen lässt, reicht die Wirkung vom Ausbruch aus dem Arbeitsverzeichnis bis zur Kompromittierung des macOS-Hosts.

Die zweite Lücke CVE-2026-79994 betrifft den Unix-Domain-Socket-Relay zwischen Gast und Host. Der Relay prüfte zwar, ob ein Socket-Pfad innerhalb eines erlaubten Arbeitsbereichs liegt, verband sich danach aber erneut über den Pfadnamen statt über eine sicher festgehaltene Dateireferenz. Zwischen Prüfung und Verbindungsaufbau konnte ein bösartiger Gast ein Zwischenverzeichnis durch einen Symlink ersetzen. Der Host verband sich dann mit einem beliebigen AF_UNIX-Socket außerhalb des Arbeitsbereichs. Beide Fälle sind klassische Time-of-Check-to-Time-of-Use-Fehler.

CVE	Einstufung	Betroffene Versionen	Behoben in
CVE-2026-77179	Kritisch, CVSSv4 9.4 laut Fachbericht	0.28.0 bis vor 0.42.0, nur macOS	0.42.0
CVE-2026-79994	Hoch, CVSSv4 8.7 laut Fachbericht	0.37.0 bis vor 0.42.0	0.42.0

Hinweis zur Einordnung der Zahlen: Die Einstufungen Kritisch und Hoch stammen aus der offiziellen Docker-Sicherheitsmeldung. Die konkreten CVSSv4-Werte 9.4 und 8.7 stammen aus der Fachberichterstattung und sind dort tabellarisch ausgewiesen.

Wer ist betroffen?

Betroffen sind Arbeitsplätze, auf denen Docker Sandboxes tatsächlich genutzt wird. Für die kritische Lücke gilt zusätzlich die Einschränkung auf macOS.

• Betroffen: macOS-Entwicklergeräte mit Docker Sandboxes zwischen 0.28.0 und 0.41.x, insbesondere wenn dort KI-Agenten oder fremder Code laufen.
• Betroffen, geringere Einstufung: Installationen ab 0.37.0 bis vor 0.42.0 wegen der Socket-Relay-Lücke.
• Nicht betroffen: Linux-Server mit reiner Docker Engine, ohne Docker Desktop und ohne Sandboxes.
• Nicht betroffen von der kritischen Lücke: Windows-Installationen. Docker beschränkt CVE-2026-77179 ausdrücklich auf macOS.
• Nicht betroffen: Docker-Desktop-Nutzer, die die Sandboxes-Funktion nie aktiviert haben.

Zum Zeitpunkt der Veröffentlichung dieses Beitrags ist laut den ausgewerteten Quellen weder eine aktive Ausnutzung noch ein öffentlicher Proof of Concept bekannt.

Wie kritisch ist das?

Der Angriffspfad ist ein Ausbruch aus der Isolation, keine Remote Code Execution über das Netzwerk. Niemand kann diese Lücke über das Internet gegen einen Mac auslösen, ohne dass zuvor Code in der Sandbox gestartet wurde. Wer die Sandbox ausschließlich für eigenen, geprüften Code nutzt, hat ein deutlich kleineres Risiko.

Die hohe Einstufung ergibt sich aus dem Zweck der Funktion. Sandboxes existiert, um genau den Fall abzudecken, in dem man dem Code nicht traut. Fällt die Isolation, verliert die Funktion ihren gesamten Sicherheitsnutzen. Wer einen KI-Agenten unbeaufsichtigt ein fremdes Repository bauen lässt, hat genau das Szenario vorliegen, für das die Lücke gebaut wurde.

Besonders unangenehm ist, was im Benutzerverzeichnis eines typischen Entwicklermacs liegt: SSH-Schlüssel unter ~/.ssh, Cloud-Zugangsdaten unter ~/.aws oder ~/.config/gcloud, Kubeconfig-Dateien unter ~/.kube, Docker-Registry-Tokens und Browser-Sitzungen. All das ist für den VMM-Benutzer lesbar. Ein erfolgreicher Ausbruch bedeutet deshalb im Zweifel nicht nur einen kompromittierten Laptop, sondern kompromittierte Zugänge zu Produktivsystemen.

Was sollten Admins jetzt tun?

• Inventar erstellen: Feststellen, auf welchen Macs Docker Desktop installiert ist und wo die Sandboxes-Funktion wirklich verwendet wird. Ohne diese Liste lässt sich der Aufwand nicht abschätzen.
• Version prüfen: Auf dem Gerät docker --version und docker desktop version ausführen. Die Sandboxes-Version zeigt Docker Desktop zusätzlich im Menü unter Über beziehungsweise in den Einstellungen der Sandboxes-Funktion an. Maßgeblich ist die Sandboxes-Version, nicht die Desktop-Versionsnummer.
• Aktualisieren: Auf Docker Sandboxes 0.42.0 oder neuer gehen. Der Weg führt über die Update-Funktion von Docker Desktop beziehungsweise über die Aktualisierung der Sandboxes-Komponente.
• Zwischenlösung, wenn kein Update möglich ist: Docker empfiehlt ausdrücklich, den Clone-Modus zu verwenden und auf schreibbare Host-Mounts zu verzichten. Wer die Funktion nicht braucht, schaltet sie vorübergehend ganz ab.
• Hochrisikogeräte zuerst: Macs, auf denen KI-Agenten autonom arbeiten oder fremde Kundenrepositories gebaut werden, gehören an den Anfang der Patchreihenfolge.
• Geheimnisse prüfen: Auf betroffenen Geräten nachsehen, ob SSH-Schlüssel, Cloud-Credentials, Kubeconfigs oder langlebige API-Token im Benutzerverzeichnis liegen. Diese waren potenziell lesbar.
• Im Zweifel rotieren: Wurde auf einem ungepatchten Gerät fremder Code in einer Sandbox ausgeführt, sollten die betroffenen Schlüssel und Token vorsichtshalber getauscht werden, statt auf Beweise zu warten.
• Verteilung automatisieren: Auf Firmen-Macs die Aktualisierung über das Mobile Device Management ausrollen, damit der Patchstand nicht von der Aufmerksamkeit einzelner Nutzer abhängt.
• Grundregel verankern: Keine fremden Repositories und keine ungeprüften KI-Agenten-Workflows auf Arbeitsgeräten, die gleichzeitig Zugriff auf Unternehmensdaten haben.
• Backup prüfen: Vor einem größeren Update auf verteilten Geräten sicherstellen, dass die Datensicherung der Entwicklerarbeitsplätze aktuell und wiederherstellbar ist.

Einordnung für Unternehmen

Der Fall zeigt ein Muster, das mit dem Aufkommen autonomer KI-Agenten schnell wichtiger wird. Entwicklerarbeitsplätze werden zunehmend zu Ausführungsumgebungen für Code, den niemand vorher gelesen hat. Die Sandbox ist dabei die einzige Sicherheitsgrenze. Eine einzige Symlink-Race-Bedingung in der Dateifreigabe genügt, um diese Grenze aufzuheben.

Für die Organisation heißt das zweierlei. Erstens gehört die Sandbox-Software ab sofort in dieselbe Patchdisziplin wie Browser und Betriebssystem, inklusive Versionsinventar und Nachweis. Zweitens sollte die Trennung zwischen Entwickler-Laptop und produktiven Zugangsdaten technisch erzwungen werden, nicht nur organisatorisch empfohlen. Kurzlebige Token, Hardware-gebundene SSH-Schlüssel und getrennte Konten für Test und Produktion begrenzen den Schaden, wenn eine Isolationsschicht das nächste Mal versagt.

Wer Docker Sandboxes bislang nicht nutzt, sollte die Einführung nicht wegen dieser Lücke verwerfen. Eine gepatchte Sandbox bleibt deutlich sicherer, als fremden Code direkt auf dem Arbeitsrechner laufen zu lassen. Entscheidend ist, dass die Sandbox selbst aktuell gehalten wird und man ihr nicht mehr zutraut, als sie leisten kann.

Passende Anleitungen auf S-EDV

• Docker-Container mit AppArmor und SELinux härten: zeigt, wie sich die Isolation von Containern über zusätzliche Pflichtzugriffskontrollen absichern lässt, wenn die Standardgrenze nicht reicht.
• CopyEscape: die docker-cp-Lücke CVE-2026-17106: ein sehr ähnlicher Pfad-Escape-Fehler in Docker Desktop und eine gute Einordnung, warum Pfadprüfungen so oft fehlschlagen.
• Docker Model Runner CVE-2026-28400: erklärt den Update-Weg von Docker Desktop und das Prüfen des installierten Versionsstands.

Quellen

• Docker Security Announcements: Docker Sandboxes 0.42.0 security update, Primärquelle des Herstellers, abgerufen am 19.09.2026.
• The Hacker News: Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files, 17.09.2026.
• securityonline.info: Critical Docker Sandboxes Vulnerabilities Patched, 17.09.2026, mit CVSSv4-Werten.
• Cyber Security News: Critical Docker Sandbox Vulnerabilities Enable Malicious Guests to Escape Isolated microVM Workspaces, 17.09.2026.