Der Ausbruch führte über den virtio-fs-Host-Server, also die Host-Seite der Dateifreigabe zwischen dem Mac und der virtuellen Maschine. Dieser folgte laut Docker Symlinks, wenn er eine entfernte Datei über einen gespeicherten Pfad erneut öffnete. Ein Gast — alles, was innerhalb der VM läuft — konnte damit ein übergeordnetes Verzeichnis durch einen Symlink ersetzen und anschließend Dateien als VMM-Benutzer lesen oder ändern, also unter dem Host-Konto, unter dem der Virtual Machine Monitor läuft. Das führe “möglicherweise zur Codeausführung auf dem Host”, so Docker.
Das widerspricht der eigenen Dokumentation: Dort heißt es seit März, dass Symlinks, die aus dem Workspace — Dockers Bezeichnung für das freigegebene Projektverzeichnis — hinausweisen, nicht verfolgt werden.
Dasselbe Release behebt eine zweite Schwachstelle, CVE-2026-79994, die Docker als hoch mit einem CVSS-Wert von 8,7 einstuft. Sie betrifft das Relay, über das eine Sandbox Unix-Domain-Sockets innerhalb ihres autorisierten Workspace erreichen kann. Das Relay prüfte, ob ein Socket-Pfad innerhalb des Workspace lag, und verband sich anschließend erneut über den Pfadnamen. Ersetzte ein Gast zwischen Prüfung und Verbindungsaufbau ein Verzeichnis im Pfad durch einen Symlink, konnte er den Host dazu bringen, sich mit einem beliebigen AF_UNIX-Socket außerhalb des Workspace zu verbinden und so “Daten oder host-seitige Fähigkeiten dieses Sockets offenzulegen”. Betroffen sind die Versionen 0.37.0 bis 0.41.9, nicht aber 0.42.0. Auch hier führt CISA die Ausnutzung als “keine”, und die Lücke steht nicht im KEV-Katalog.
Auffällig ist die Plattformangabe: Docker bezeichnet die erste Lücke als macOS-spezifisch, nennt für die zweite aber keine Plattform — Docker Sandboxes läuft auf macOS-, Windows- und Linux-Hosts.
Standardmäßig teilt “sbx run” das aktuelle Verzeichnis mit Lese- und Schreibzugriff in die Sandbox. Der Clone-Modus funktioniert nur, wenn das Projekt ein Git-Repository ist, und wird beim Anlegen der Sandbox festgelegt; eine bestehende Sandbox muss also entfernt und mit –clone neu erstellt werden. Er schützt das Repository allerdings nur vor Änderungen, nicht vor dem Lesen: Das Repository wird schreibgeschützt unter /run/sandbox/source eingebunden, unversionierte Dateien wie .env bleiben laut Dockers Dokumentation innerhalb der Sandbox lesbar.
Docker veröffentlichte die CVE-Einträge und die Mitteilung am 15. September, acht Tage nach dem Erscheinen von 0.42.0. Die Release Notes zu 0.42.0 auf GitHub und auf Dockers Dokumentationsseite nennen mit Stand 17. September keine der beiden CVE-Nummern. Unter den Routine-Korrekturen wird eine aufgeführt, bei der “ein Prozess in der Sandbox den Daemon dazu bringen konnte, einen Host-D-Bus-Transport zu öffnen und einen beliebigen Befehl auf dem Host auszuführen” — eine Verbindung zu einer der beiden CVEs stellt Docker nicht her. Im Eintrag zu CVE-2026-79994 stand zunächst 0.41.0 als erste behobene Version, verlinkt auf eine nicht existierende Release-Seite; Docker korrigierte beides etwa eine Stunde nach der Veröffentlichung am 15. September auf 0.42.0.
Als Entdecker nennt Docker Oren Yomtov von accomplish.ai für CVE-2026-77179 und Jurre van Bergen von ThreatNotify für CVE-2026-79994. Cyera Research Labs hatte im April beschrieben, wie ein per Prompt Injection manipulierter Coding-Agent in einer Docker-basierten Sandbox dazu verleitet werden konnte, eine separate Docker-Engine-Lücke gegen seinen Host auszunutzen.