Kritische Docker-Sandbox-Lücke öffnet macOS-Host für Angreifer : Fehler in virtio-fs und Unix-Socket-Relay durchbrechen die Isolation von KI-Agenten

Docker warnt vor zwei Schwachstellen in Docker Sandboxes, die genau jene Isolation unterlaufen, auf die sich Entwickler beim Ausführen autonomer Coding-Agenten verlassen. Besonders kritisch ist CVE-2026-77179: Schadcode innerhalb einer Sandbox konnte über die gemeinsame Dateifreigabe aus dem vorgesehenen Workspace ausbrechen und beliebige Dateien auf dem macOS-Host lesen oder verändern. Docker beschreibt die Details in einer Sicherheitsmitteilung.

Docker Sandboxes startet jeden KI-Coding-Agenten in einer eigenen kleinen virtuellen Maschine (VM). Das Projektverzeichnis des Hosts wird in diese VM eingebunden. Gerade weil Agenten innerhalb der VM Pakete installieren und Befehle mit Root-Rechten ausführen können, soll die Hypervisor-Grenze den Host schützen. Docker formuliert dies in seiner Dokumentation zur Isolation ausdrücklich: Nicht die Rechtevergabe innerhalb der VM, sondern der Hypervisor bildet die eigentliche Sicherheitsgrenze.

Symlink-Trick durchbricht virtio-fs-Isolation

CVE-2026-77179 betrifft den virtio-fs-Host-Server, der Dateifreigaben zwischen macOS und der VM vermittelt. Der Fehler trat auf, wenn eine bereits entfernte Datei über einen gespeicherten Pfad erneut geöffnet wurde. Dabei folgte der Host-Server symbolischen Links. Ein Gastprozess konnte dadurch ein übergeordnetes Verzeichnis durch einen Symlink ersetzen. Beim erneuten Zugriff wurde der Pfad außerhalb des freigegebenen Workspaces aufgelöst. Der Schadcode erhielt so Zugriff mit den Rechten des Accounts, unter dem der Virtual Machine Monitor (VMM) lief. Docker warnt, dies könne „potenziell zur Codeausführung auf dem Host“ führen.

Brisant ist dabei, dass Docker bereits seit März dokumentiert hatte, dass Symlinks außerhalb des Workspaces nicht verfolgt werden sollten. Der Fehler lag somit nicht in einer offensichtlichen Konfiguration, sondern im Verhalten des Host-seitigen Dateiservers.

Betroffen sind Docker Sandboxesab Version 0.28.0 bis einschließlich 0.41.x auf macOS. Docker bewertet die Schwachstelle als kritisch mit CVSS 9,4. Behoben wurde sie in Version 0.42.0. Der zugehörige CVE-Eintrag nennt bislang keine bekannte Ausnutzung.

Zweite Lücke missbraucht Unix-Sockets

Eine zweite von dieser Docker-Version geschlossene Schwachstelle wird unter CVE-2026-79994 geführt. Sie betrifft die Relay-Funktion, über die eine Sandbox auf Unix Domain Sockets innerhalb eines für sie freigegebenen Arbeitsverzeichnisses zugreifen kann. Das Relay fungiert also als Vermittler zwischen der isolierten Sandbox und lokalen Unix-Sockets auf dem Host beziehungsweise im freigegebenen Dateibereich. Genau in diesem Vermittlungsmechanismus steckt die Schwachstelle.

Das Relay prüfte zunächst, ob ein Socket-Pfad innerhalb des erlaubten Workspaces lag. Anschließend stellte es die Verbindung anhand desselben Pfadnamens her. Zwischen Prüfung und Nutzung konnte ein Gast jedoch ein Verzeichnis durch einen Symlink ersetzen – ein klassischer Time-of-Check-to-Time-of-Use-Fehler (TOCTOU). Dadurch konnte der Host mit beliebigen AF_UNIX-Sockets außerhalb des erlaubten Bereichs verbunden werden. Docker zufolge konnten so Daten oder Host-Funktionen offengelegt werden, die über den jeweiligen Socket erreichbar waren.

CVE-2026-79994 betrifft Versionen 0.37.0 bis 0.41.9 und wird mit CVSS 8,7 als hoch eingestuft. Der CVE-Datensatz nennt ebenfalls keine bekannte Ausnutzung.

Betroffene Versionen und Gegenmaßnahmen

Docker empfiehlt zwei Maßnahmen:

• Auf Version 0.42.0 oder neuer aktualisieren. Am 17. September war bereits Version 0.43.0 verfügbar. Die Release Notes zu 0.42.0 nennen die beiden CVEs allerdings nicht ausdrücklich.
• Falls ein Update nicht sofort möglich ist, Clone Mode verwenden und keine zusätzlichen Read-Write-Host-Mounts einbinden. Hinweise dazu liefert die Dokumentation zum Clone Mode.

Dabei bleibt eine Einschränkung: Clone Mode schützt das Repository vor Veränderungen, nicht vor dem Lesen. Das Git-Repository wird unter /run/sandbox/source schreibgeschützt eingebunden, nicht versionierte Dateien wie .env bleiben innerhalb der Sandbox jedoch lesbar.

Warum KI-Agenten das Risiko verschärfen

Die Schwachstellen sind besonders relevant, weil Coding-Agenten gerade dafür ausgelegt sind, selbstständig Pakete zu installieren, Werkzeuge aufzurufen und Code auszuführen. Gelangt ein Agent durch Prompt Injection oder manipulierte Projektinhalte unter fremde Kontrolle, kann er vorhandene Sandbox-Lücken aktiv ausnutzen. Damit verschiebt sich das Bedrohungsmodell: Nicht nur absichtlich eingeschleuster Schadcode ist kritisch. Auch ein zunächst legitimer KI-Agent kann zum Angriffsvektor werden, sobald er dazu gebracht wird, unerwünschte Befehle innerhalb der Sandbox auszuführen. Ein vergleichbares Muster hatte Cyera Research Labs bereits im April beschrieben: Ein per Prompt Injection manipulierter Coding-Agent konnte innerhalb einer Docker-basierten Sandbox eine separate Schwachstelle in Docker Engine gegen den Host ausnutzen.

Isolation ist nur so stark wie ihre Host-Grenze

Für Unternehmen ist damit vor allem eines relevant: Eine Sandbox für KI-Agenten darf nicht als absoluter Sicherheitscontainer verstanden werden. Sobald Agenten mit Host-Verzeichnissen, Sockets oder anderen Host-Ressourcen interagieren, wird die Implementierung dieser Übergänge zum zentralen Risiko.

Die beiden Docker-Lücken zeigen, dass selbst sauber gedachte Isolation durch Details wie Symlink-Auflösung oder Pfadprüfungen ausgehebelt werden kann. Wer autonome Coding-Agenten produktiv einsetzt, sollte deshalb nicht nur die Agenten selbst kontrollieren, sondern ebenso die Virtualisierungs-, Mount- und Host-Integrationsschicht konsequent patchen und überwachen.