Docker heeft op 15 september een beveiligingsmelding gepubliceerd over een Docker Sandboxes lek dat kwaadaardige code binnen een sandbox-virtuele machine kan laten ontsnappen aan de gedeelde projectmap. Het gevolg kan zijn dat bestanden op de macOS-host gelezen of aangepast worden, met rechten van de gebruiker die de sandbox draait.
Op CISA-niveau is er tot dusver geen melding van daadwerkelijke misbruikte exploitatie. Toch is de impact relevant voor organisaties die AI-coding agents of andere geautomatiseerde processen in Docker Sandboxes uitvoeren, omdat die software vaak tools en pakketten installeert en commando’s draait.
Wat houdt de Docker Sandboxes lek precies in?
De kritieke kwetsbaarheid draagt de naam CVE-2026-77179 en is door Docker als Critical geclassificeerd. Ze treft volgens de aankondiging macOS-versies vanaf 0.28.0 tot en met, maar niet inclusief 0.42.0. De fix is uitgebracht in 0.42.0 (gepubliceerd op 7 september).
Docker Sandboxes draait elk AI-coding agent in een kleine virtuele machine. Daarbij wordt het projectgedeelte (de “workspace”) gedeeld met de sandbox. De crux van het probleem: binnen de sandbox kan code draaien die — als die kwaadwillend is — via de file-sharing laag verder kan reiken dan de bedoeling.
Docker benadrukt dat de aanval afhangt van malicious code die daadwerkelijk binnen de sandbox draait. De sandbox is juist bedoeld om te voorkomen dat wat een agent uitvoert gevolgen heeft buiten zijn eigen afscherming.
Hoe kan ontsnapping gebeuren op macOS?
De escape verloopt volgens Docker via virtio-fs, specifiek de host-side file server van de gedeelde mappen tussen macOS en de virtuele machine.
Wat er misgaat, is het heropenen van een verwijderd bestand op een opgeslagen pad. Hierbij volgt de hostkant symlinks wanneer het systeem het pad opnieuw opent. Een “guest” (wat er ook in de virtuele machine draait) kan in de tussenliggende stappen een ouderdirectory vervangen door een symlink, waarna de sandboxcode bestanden kan lezen of aanpassen alsof het proces draait onder de VMM-gebruiker.
Docker geeft aan dat documentatie al sinds maart stelt dat symlinks die naar buiten de workspace wijzen, niet gevolgd zouden moeten worden. De kwetsbaarheid laat zien dat die bescherming in bepaalde scenario’s toch doorbroken kan worden.
Ook: een tweede issue met invloed op Unix-sockets
Dezelfde release lost daarnaast een tweede kwetsbaarheid op: CVE-2026-79994. Deze is door Docker als High beoordeeld met een CVSS-score van 8.7.
Hier gaat het niet primair om lezen of wijzigen van bestanden, maar om de manier waarop een sandbox verbinding maakt met Unix domain sockets (AF_UNIX). Het systeem controleert eerst of een socketpad binnen de workspace ligt. Daarna wordt de verbinding hersteld met de padnaam.
Docker beschrijft dat een “guest” de situatie kan uitbuiten door tussen de check en de verbinding een directory langs dat pad te vervangen door een symlink. Daardoor kan de host uiteindelijk connectie maken met een AF_UNIX socket buiten de workspace.
De potentiële impact: dataleaks of het benutten van host-side mogelijkheden die via die socket beschikbaar zijn.
Wie loopt risico en wanneer?
Beide problemen veronderstellen dat er kwaadaardige code in de sandbox terechtkomt. Dat kan bijvoorbeeld gebeuren wanneer een AI-coding agent wordt misbruikt, of wanneer een agent een kwaadaardig pakket installeert en uitvoert. Docker noemt expliciet dat de sandbox ook kan draaien wat een agent “tegen” de gebruiker maakt, of wat een agent zelf — met of zonder kwaadwillend doel — installeert en start.
Daarnaast wijst Docker erop dat de agent commando’s draait met sudo binnen de virtuele machine. Dat is precies waarom de isolatiegrens belangrijk is: Docker geeft aan dat de hypervisorgrens de isolatiecontrol is, en niet “privilege separation” binnen de VM.
Voor organisaties betekent dit: het risico is vooral aanwezig in omgevingen waar sandboxed processen niet volledig te vertrouwen zijn. Denk aan workflows waarbij externe code, onbeperkte scripts of door gebruikers aangeleverde content in de agent terecht kan komen.
Is er al misbruik vastgesteld?
Docker heeft tot nu toe geen gerapporteerde exploitatie gemeld. Ook CISA’s assessment op het CVE-record geeft aan dat er geen actieve exploitatie is vastgesteld, en de kwetsbaarheden staan niet in de CISA Known Exploited Vulnerabilities-catalogus (zoals die op 16 september is uitgebracht).
Dat betekent niet dat er geen impact kan zijn. Het is juist een signaal om niet te wachten: een kritieke kwetsbaarheid met sandbox escape-capaciteiten is het type issue dat bij misbruik snel schaal kan krijgen, zodra de juiste payloads beschikbaar zijn.
Wat moet je nu doen: update en noodmaatregelen
Docker’s advies is helder: update naar 0.42.0 of later. Ten tijde van de aankondiging was de meest recente release 0.43.0 (gepubliceerd op 15 september).
Kun je (nog) niet updaten, dan raadt Docker aan om te werken met clone mode en om read-write host mounts te vermijden.
Clone mode: helpt dit, maar niet overal
Clone mode werkt alleen wanneer het project een Git repository is. De optie wordt ingesteld bij het aanmaken van een sandbox. Bestaande sandboxen moet je daarom verwijderen en opnieuw aanmaken met de juiste parameter.
Belangrijk nuancepunt: clone mode beschermt vooral tegen wijzigingen aan de repository, maar volgens Docker blijft het lezen van bepaalde bestanden mogelijk. Zo wordt de repository standaard read-only gemount naar /run/sandbox/source, terwijl niet-getraceerde bestanden zoals .env binnen de sandbox nog wel leesbaar kunnen zijn.
Met andere woorden: clone mode is een stap in de goede richting, maar het vervangt een patch niet.
Extra aandacht: interactie met de sandbox-omgeving
Docker noemt in de toelichting dat het gaat om ontsnapping via de virtio-fs hostserver en via een relay voor verbindingen naar Unix domain sockets. Die details laten zien dat de zwakke plek niet alleen in “code binnen de VM” zit, maar in de manier waarop de host met de sandbox integreert.
Er werd in de release notes bovendien verwezen naar een situatie waarin een gesandboxd proces de daemon kan laten openen van een host D-Bus transport en vervolgens een willekeurig commando op de host kan uitvoeren. Docker koppelt die fix in de gepubliceerde informatie niet expliciet aan een van de genoemde CVE’s, maar het toont wel dat er meer dan één laag is waar isolatie mis kan lopen.
Ook relevant: Docker’s release-advisory werd acht dagen na het verschijnen van 0.42.0 gepubliceerd. Daarnaast zijn er correcties geweest in het CVE-record voor CVE-2026-79994, waaronder de eerste vaste versie en een foutieve verwijzing naar een releasepagina.
Praktische checklist voor teams met Docker Sandboxes
- Patch direct: upgrade naar 0.42.0 of later (bij voorkeur de nieuwste release).
- Check je sandboxconfiguratie: controleer of je workflows read-write host mounts gebruiken.
- Gebruik clone mode als tussenoplossing: alleen mogelijk bij Git-repositories en vereist een nieuwe sandbox.
- Beperk data-injectie: behandel input naar coding agents als risicovol, omdat “malicious code in the sandbox” de randvoorwaarde is.
- Voorkom dat sensibele bestanden onnodig leesbaar worden: houd rekening met bestanden die als .env in de werkdirectory staan.
Verwant risico: supply chain en misbruik van agents
Dit type kwetsbaarheid past in een breder patroon: wanneer geautomatiseerde tooling in een omgeving met software-installaties draait, kan een aanval zich via de supply chain of via prompt-gedreven gedragingen verplaatsen. Dat is een reden waarom organisaties niet alleen naar applicatiepatches kijken, maar ook naar hoe isolatie werkt bij build- en testomgevingen.
Als je dit onderwerp verder wilt plaatsen in de context van ketenrisico’s, lees dan ook waarom ransomware bij fabrikanten supply chain in gevaar kan brengen. En voor het benaderen van risico met continue zekerheidsmaatregelen is continue controle: bewijzen of een CVE echt te misbruiken is een nuttig vervolg.
Conclusie
De Docker Sandboxes lekken CVE-2026-77179 (kritiek op macOS) en CVE-2026-79994 (high, met socket-gerelateerde impact) laten zien dat sandboxen alleen veilig zijn wanneer de isolatiegrenzen in alle scenario’s standhouden. De aanval vereist kwaadaardige code in de sandbox, maar dat is precies het risico bij AI-coding agents die code en commando’s uitvoeren.
Update daarom naar 0.42.0 of later. Lukt dat niet meteen, gebruik dan Docker’s tussenmaatregel clone mode en vermijd read-write host mounts. Daarmee verklein je de kans op ongewenste lees- en wijzigingsacties buiten de workspace, maar de patch blijft de belangrijkste stap.
Bron: https://thehackernews.com/2026/09/critical-docker-sandboxes-flaw-lets.html
