Vulnerabilità Docker Sandboxes su macOS risolta nella versione 0.42.0

Docker ha reso nota una vulnerabilità critica in Docker Sandboxes su macOS che permetteva a codice malevolo in esecuzione all'interno di una sandbox di raggiungere file in qualsiasi altra posizione del Mac, e l'azienda ha già rilasciato una correzione.

La falla è tracciata come CVE-2026-77179, dove CVE sta per Common Vulnerabilities and Exposures, un identificatore pubblico assegnato a un bug di sicurezza affinché tutti descrivano lo stesso problema con lo stesso nome. Docker la classifica come Critica con un punteggio CVSS di 9,4. CVSS è il Common Vulnerability Scoring System, una scala da 0 a 10 che il settore usa per indicare quanto è grave una falla, quindi 9,4 si colloca vicino al massimo. Interessa le versioni di Docker Sandboxes dalla 0.28.0 fino alla 0.42.0 esclusa su macOS ed è stata corretta nella 0.42.0 il 7 settembre. Docker ha pubblicato i record CVE e il suo annuncio di sicurezza il 15 settembre, otto giorni dopo la comparsa della versione corretta, quindi chi ha installato l'aggiornamento non appena è stato disponibile è stato protetto prima che i dettagli diventassero pubblici. L'evasione opera con i diritti dell'account host che esegue la macchina virtuale, il che significa che non richiede privilegi aggiuntivi propri.

Docker Sandboxes è progettato per eseguire ogni agente di coding AI all'interno della propria piccola macchina virtuale, ovvero un computer simulato via software e tenuto separato dalla macchina reale, con la directory del progetto condivisa al suo interno. Il codice che poteva evadere è qualunque cosa venga eseguita dentro quella macchina: un agente di coding volto contro il proprio utente, o qualsiasi cosa malevola che l'agente installa ed esegue. Questo è il punto che conta, perché proteggere l'host da ciò che fa un agente è esattamente lo scopo per cui esiste la sandbox, e questa falla era la lacuna in quella protezione. Gli agenti installano pacchetti ed eseguono comandi con sudo, cioè con diritti di amministratore, all'interno della macchina virtuale, e la documentazione sull'isolamento di Docker afferma che il confine dell'hypervisor, lo strato che separa la macchina virtuale dalla macchina sottostante, "è il controllo di isolamento, non la separazione dei privilegi all'interno della VM". Docker sta dicendo che si affida al muro attorno alla macchina virtuale piuttosto che ai permessi al suo interno.

Secondo Docker, l'evasione è passata attraverso il server host virtio-fs, il lato host del meccanismo di condivisione file tra il Mac e la macchina virtuale, che seguiva i symlink quando riapriva un file che era stato rimosso, usando un percorso memorizzato. Un symlink è un piccolo file che funge da scorciatoia che punta a un altro file o cartella, e seguirne uno è il modo in cui un programma viene indirizzato a guardare altrove rispetto a dove intendeva. Un guest, cioè qualunque cosa venga eseguita dentro la macchina virtuale, poteva sostituire una directory padre con un symlink e poi leggere o modificare file come utente VMM, l'account host sotto cui opera il monitor della macchina virtuale, il programma che esegue la macchina virtuale, ha detto Docker, "potenzialmente portando all'esecuzione di codice sull'host". Esecuzione di codice sull'host significa che il programma di un attaccante viene eseguito sul Mac stesso anziché dentro la macchina sigillata. La documentazione di Docker afferma da marzo che i symlink che puntano fuori dal workspace, il suo nome per la directory di progetto condivisa, non vengono seguiti.

La stessa release 0.42.0 corregge anche una seconda vulnerabilità, CVE-2026-79994, che Docker classifica come Alta con un punteggio CVSS di 8,7. Si trova nel relay che consente a una sandbox di connettersi ai socket di dominio Unix all'interno del suo workspace autorizzato. Un socket di dominio Unix è un canale che i programmi sullo stesso computer usano per parlarsi. Il relay verificava che un percorso di socket fosse all'interno del workspace e poi si riconnetteva usando il nome del percorso, e un guest che sostituiva una directory lungo quel percorso con un symlink tra il controllo e la connessione poteva far connettere l'host a qualsiasi socket AF_UNIX al di fuori del workspace, ha detto Docker, "esponendo dati o capacità lato host fornite da quel socket". In altre parole, il controllo di sicurezza e l'azione avvenivano in momenti diversi, e la risposta cambiava nel frattempo. Questa falla interessa le versioni dalla 0.37.0 alla 0.41.9, ma non la 0.42.0. Docker elenca la prima falla come solo macOS ma non indica alcuna piattaforma per la seconda, anche se Docker Sandboxes funziona su host macOS, Windows e Linux, quindi la seconda potrebbe arrivare più lontano della prima.

Docker non ha segnalato alcuno sfruttamento di nessuna delle due falle. La valutazione aggiunta di CISA sul record CVE-2026-77179 elenca lo sfruttamento come nessuno, e la falla non è nel catalogo Known Exploited Vulnerabilities di CISA, un elenco che l'agenzia mantiene delle falle che gli attaccanti sono noti per aver usato in attacchi reali, alla versione del catalogo rilasciata il 16 settembre. Lo stesso vale per CVE-2026-79994, il cui record elenca anch'esso lo sfruttamento come nessuno e che è parimenti assente da quel catalogo. Sfruttare la prima falla richiede che del codice malevolo sia già in esecuzione dentro la sandbox, che è esattamente ciò che una sandbox è progettata per contenere. Docker attribuisce a Oren Yomtov di accomplish.ai la scoperta di CVE-2026-77179 e a Jurre van Bergen di ThreatNotify la scoperta di CVE-2026-79994.

Il rimedio è semplice. Primo, aggiornare alla 0.42.0 o successiva; al 17 settembre la release più recente è la 0.43.0, pubblicata il 15 settembre. Secondo, se non si può ancora aggiornare, Docker consiglia di usare la modalità clone ed evitare mount host in lettura-scrittura, che è la sua raccomandazione per entrambe le falle.

Per impostazione predefinita, il comando sbx run condivide la directory corrente nella sandbox con accesso in lettura e scrittura. La modalità clone funziona solo quando il progetto è un repository Git, Git essendo il sistema di controllo versione che molti sviluppatori usano per tracciare le modifiche al codice, e viene scelta quando la sandbox viene creata, quindi una sandbox esistente deve essere rimossa e ricreata con l'opzione --clone. La modalità clone protegge il repository dalle modifiche, non dalla lettura. Il repository è montato in sola lettura su /run/sandbox/source, e i file non tracciati come .env, un luogo comune dove tenere password e chiavi API, restano leggibili dentro la sandbox, secondo la documentazione di Docker. Chi considera la modalità clone una protezione completa dovrebbe conoscere questo limite.

Alcuni dettagli restano non documentati. Le note di rilascio della 0.42.0 su GitHub e sul sito di documentazione di Docker non nominano nessuno dei due CVE al 17 settembre. Tra le correzioni di routine ne elencano una per un caso in cui "un processo in sandbox poteva far aprire al daemon un trasporto D-Bus dell'host ed eseguire un comando arbitrario sull'host", il daemon essendo il servizio in background che svolge attività sulla macchina host e D-Bus un sistema di messaggistica che i programmi sullo stesso computer usano per parlarsi, e Docker non ha collegato quella correzione a nessuno dei due CVE. Il record di CVE-2026-79994 elencava inizialmente la 0.41.0 come prima versione corretta e rimandava a una pagina di rilascio 0.41.0 che non esiste; Docker ha corretto entrambi in 0.42.0 circa un'ora dopo aver pubblicato il record il 15 settembre.

Gli agenti AI in sandbox sono già stati esaminati in passato per cercare vie d'uscita. In aprile, Cyera Research Labs ha descritto come un agente di coding soggetto a prompt injection dentro una sandbox basata su Docker potesse essere indotto a sfruttare una falla separata di Docker Engine contro il suo host. Un prompt injection si verifica quando il testo che un agente AI legge contiene istruzioni nascoste che lo indirizzano verso qualcosa che il suo utente non ha mai chiesto. Quel lavoro riguardava una falla diversa e uno scenario diverso, e Docker non lo ha collegato ai due CVE qui descritti.

Per i team che sperimentano con agenti di coding AI, la lezione pratica è che una sandbox è forte solo quanto il confine che la circonda, e riparare il confine significa aggiornare. Entrambe le falle sono state corrette prima di essere annunciate, quindi il giorno in cui Docker ha parlato, un controllo della versione era tutto il lavoro da fare. Dove gli agenti sono autorizzati a girare su macchine che contengono anche codice aziendale, credenziali o dati dei clienti, mantenere la sandbox aggiornata e limitare quanto dell'host viene condiviso al suo interno sono le due abitudini che contano di più. Le organizzazioni che desiderano una visione esterna di come le loro macchine degli sviluppatori, i sistemi di build e l'infrastruttura ospitata sono separati l'uno dall'altro possono guardare ad AEU-I, che fornisce IT, infrastruttura e consulenza security-first, e le cui pagine pubbliche descrivono le valutazioni e il lavoro di hardening che svolge.