Docker Sandboxes Schwachstelle auf macOS in Version 0.42.0 gepatcht

Docker hat eine kritische Schwachstelle in Docker Sandboxes auf macOS offengelegt, die es bösartigem Code, der in einer Sandbox läuft, ermöglichte, auf Dateien an beliebiger anderer Stelle auf dem Mac zuzugreifen, und das Unternehmen hat bereits einen Fix veröffentlicht.

Die Schwachstelle wird als CVE-2026-77179 geführt, wobei CVE für Common Vulnerabilities and Exposures steht, eine öffentliche Kennung, die einem Sicherheitsfehler zugewiesen wird, damit alle dasselbe Problem mit demselben Namen beschreiben. Docker bewertet sie als Critical mit einem CVSS-Score von 9.4. CVSS ist das Common Vulnerability Scoring System, eine Skala von 0 bis 10, die die Industrie verwendet, um anzugeben, wie schwerwiegend eine Schwachstelle ist, sodass 9.4 nahe am oberen Ende liegt. Sie betrifft Docker Sandboxes Versionen 0.28.0 bis ausschließlich 0.42.0 auf macOS und wurde in 0.42.0 am 7. September behoben. Docker veröffentlichte die CVE-Einträge und seine Sicherheitsankündigung am 15. September, acht Tage nachdem die korrigierte Version erschienen war, sodass jeder, der das Update installierte, sobald es verfügbar war, geschützt war, bevor die Details öffentlich wurden. Der Escape läuft mit den Rechten des Host-Kontos, das die virtuelle Maschine ausführt, was bedeutet, dass er keine eigenen zusätzlichen Privilegien benötigt.

Docker Sandboxes ist darauf ausgelegt, jeden KI-Coding-Agenten in einer eigenen kleinen virtuellen Maschine auszuführen, einem in Software simulierten Computer, der vom echten Computer getrennt gehalten wird, wobei das Projektverzeichnis hineingeteilt wird. Der Code, der ausbrechen konnte, ist alles, was in dieser Maschine läuft: ein Coding-Agent, der gegen seinen eigenen Benutzer gewendet wurde, oder alles Bösartige, was der Agent installiert und ausführt. Das ist der entscheidende Punkt, denn den Host vor dem zu schützen, was ein Agent tut, ist genau das, wofür die Sandbox existiert, und diese Schwachstelle war die Lücke in diesem Schutz. Agenten installieren Pakete und führen Befehle mit sudo aus, also mit Administratorrechten, innerhalb der virtuellen Maschine, und Dockers Isolationsdokumentation stellt fest, dass die Hypervisor-Grenze, die Schicht, die die virtuelle Maschine vom darunterliegenden Computer trennt, „die Isolationskontrolle ist, nicht die Privilegientrennung innerhalb der VM“. Docker sagt damit, dass es sich auf die Mauer um die virtuelle Maschine verlässt und nicht auf Berechtigungen innerhalb derselben.

Laut Docker verlief der Escape über den virtio-fs-Host-Server, die Host-Seite des Dateifreigabemechanismus zwischen dem Mac und der virtuellen Maschine, der Symlinks folgte, als er eine Datei erneut öffnete, die entfernt worden war, unter Verwendung eines gespeicherten Pfads. Ein Symlink ist eine kleine Datei, die als Verknüpfung fungiert, die auf eine andere Datei oder einen anderen Ordner zeigt, und einem solchen zu folgen ist der Weg, ein Programm dazu zu bringen, woanders nachzusehen, als beabsichtigt. Ein Gast, also alles, was in der virtuellen Maschine läuft, konnte ein übergeordnetes Verzeichnis durch einen Symlink ersetzen und dann Dateien als der VMM-Benutzer lesen oder ändern, das Host-Konto, unter dem der Virtual Machine Monitor, das Programm, das die virtuelle Maschine ausführt, arbeitet, so Docker, „was möglicherweise zur Codeausführung auf dem Host führt“. Codeausführung auf dem Host bedeutet, dass ein Programm eines Angreifers auf dem Mac selbst läuft und nicht in der abgeschotteten Maschine. Dockers Dokumentation besagt seit März, dass Symlinks, die aus dem Workspace, ihrem Namen für das geteilte Projektverzeichnis, herauszeigen, nicht verfolgt werden.

Dieselbe Version 0.42.0 behebt auch eine zweite Schwachstelle, CVE-2026-79994, die Docker als High mit einem CVSS-Score von 8.7 bewertet. Sie befindet sich im Relay, der es einer Sandbox ermöglicht, sich mit Unix-Domain-Sockets innerhalb ihres autorisierten Workspace zu verbinden. Ein Unix-Domain-Socket ist ein Kanal, den Programme auf demselben Computer nutzen, um miteinander zu kommunizieren. Das Relay prüfte, ob ein Socket-Pfad innerhalb des Workspace lag, und verband sich dann unter Verwendung des Pfadnamens erneut, und ein Gast, der ein Verzeichnis entlang dieses Pfads zwischen der Prüfung und der Verbindung durch einen Symlink ersetzte, konnte den Host dazu bringen, sich mit jedem AF_UNIX-Socket außerhalb des Workspace zu verbinden, so Docker, „wodurch Daten oder hostseitige Fähigkeiten, die dieser Socket bereitstellt, offengelegt werden“. Mit anderen Worten: Die Sicherheitsprüfung und die Aktion fanden zu unterschiedlichen Zeitpunkten statt, und die Antwort änderte sich dazwischen. Diese Schwachstelle betrifft Versionen 0.37.0 bis 0.41.9, aber nicht 0.42.0. Docker listet die erste Schwachstelle als nur macOS betreffend, gibt jedoch für die zweite keine Plattform an, obwohl Docker Sandboxes auf macOS-, Windows- und Linux-Hosts läuft, sodass die zweite weiter reichen könnte als die erste.

Docker hat keine Ausnutzung einer der beiden Schwachstellen gemeldet. CISAs ergänzte Bewertung im Eintrag zu CVE-2026-77179 listet die Ausnutzung als keine, und die Schwachstelle ist nicht in CISAs Known Exploited Vulnerabilities-Katalog, einer Liste, die die Behörde von Schwachstellen pflegt, die Angreifer bekanntermaßen in echten Angriffen genutzt haben, Stand der am 16. September veröffentlichten Katalogversion. Dasselbe gilt für CVE-2026-79994, dessen Eintrag ebenfalls die Ausnutzung als keine listet und der ebenso in diesem Katalog fehlt. Die Ausnutzung der ersten Schwachstelle erfordert, dass bereits bösartiger Code in der Sandbox läuft, was genau das ist, wofür eine Sandbox entwickelt wurde, um es einzudämmen. Docker dankt Oren Yomtov von accomplish.ai für die Entdeckung von CVE-2026-77179 und Jurre van Bergen von ThreatNotify für die Entdeckung von CVE-2026-79994.

Die Abhilfe ist unkompliziert. Erstens: Aktualisieren Sie auf 0.42.0 oder später; Stand 17. September ist die neueste Version 0.43.0, veröffentlicht am 15. September. Zweitens: Wenn Sie noch nicht aktualisieren können, empfiehlt Docker die Verwendung des Clone-Modus und die Vermeidung von Lese-Schreib-Host-Mounts, was seine Empfehlung für beide Schwachstellen ist.

Standardmäßig teilt der Befehl sbx run das aktuelle Verzeichnis mit Lese- und Schreibzugriff in die Sandbox. Der Clone-Modus funktioniert nur, wenn das Projekt ein Git-Repository ist, wobei Git das Versionskontrollsystem ist, das viele Entwickler verwenden, um Änderungen am Code zu verfolgen, und er wird beim Erstellen der Sandbox gewählt, sodass eine bestehende Sandbox entfernt und mit der Option --clone neu erstellt werden muss. Der Clone-Modus schützt das Repository vor Änderungen, nicht vor dem Lesen. Das Repository wird schreibgeschützt unter /run/sandbox/source eingebunden, und nicht verfolgte Dateien wie .env, ein üblicher Ort für Passwörter und API-Schlüssel, bleiben innerhalb der Sandbox lesbar, laut Dockers Dokumentation. Wer den Clone-Modus als vollständigen Schutz betrachtet, sollte diese Einschränkung kennen.

Einige Details bleiben undokumentiert. Die Versionshinweise zu 0.42.0 auf GitHub und auf Dockers Dokumentationsseite nennen Stand 17. September keine der beiden CVEs. Unter routinemäßigen Fixes listen sie einen für einen Fall, in dem „ein sandboxed Prozess den Daemon dazu bringen konnte, einen Host-D-Bus-Transport zu öffnen und einen beliebigen Befehl auf dem Host auszuführen“, wobei der Daemon der Hintergrunddienst ist, der Aufgaben auf dem Host-Rechner ausführt, und D-Bus ein Nachrichtensystem, das Programme auf demselben Computer nutzen, um miteinander zu kommunizieren, und Docker hat diesen Fix mit keiner der beiden CVEs in Verbindung gebracht. Der Eintrag zu CVE-2026-79994 listete zunächst 0.41.0 als erste korrigierte Version und verlinkte auf eine 0.41.0-Release-Seite, die nicht existiert; Docker korrigierte beides auf 0.42.0 etwa eine Stunde nach Veröffentlichung des Eintrags am 15. September.

Sandboxed KI-Agenten wurden schon früher auf Auswege untersucht. Im April beschrieb Cyera Research Labs, wie ein prompt-injizierter Coding-Agent in einer Docker-basierten Sandbox dazu verleitet werden konnte, eine separate Docker Engine-Schwachstelle gegen seinen Host auszunutzen. Eine Prompt-Injection liegt vor, wenn Text, den ein KI-Agent liest, versteckte Anweisungen enthält, die ihn zu etwas lenken, das sein Benutzer nie verlangt hat. Diese Arbeit betraf eine andere Schwachstelle und ein anderes Szenario, und Docker hat sie nicht mit den beiden hier beschriebenen CVEs in Verbindung gebracht.

Für Teams, die mit KI-Coding-Agenten experimentieren, ist die praktische Lehre, dass eine Sandbox nur so stark ist wie die Grenze um sie herum, und die Reparatur der Grenze bedeutet Aktualisieren. Beide Schwachstellen wurden gepatcht, bevor sie angekündigt wurden, sodass am Tag, an dem Docker sprach, eine Versionsprüfung die ganze Aufgabe war. Wo Agenten auf Maschinen laufen dürfen, die auch Geschäftscode, Logins oder Kundendaten enthalten, sind die Aktualisierung der Sandbox und die Begrenzung, wie viel vom Host hineingeteilt wird, die beiden wichtigsten Gewohnheiten. Organisationen, die eine externe Sicht darauf wünschen, wie ihre Entwicklermaschinen, Build-Systeme und gehostete Infrastruktur voneinander getrennt sind, können sich AEU-I ansehen, das Security-First-IT, Infrastruktur und Beratung bietet und dessen öffentliche Seiten die Assessments und Härtungsarbeiten beschreiben, die es durchführt.