Docker Sandboxes, due falle aprono il confine tra agenti AI e sistema host

🛡️ Executive Summary

• Docker corregge due vulnerabilità che permettono a un guest malevolo di oltrepassare il workspace o raggiungere socket Unix dell’host.
• La Digital Agency giapponese collega un accesso al Government Solution Service allo sfruttamento di una vulnerabilità VPN classificata inizialmente Medium.
• Il caso mostra perché isolamento e priorità di patching devono dipendere dal ruolo dell’asset, non soltanto dal punteggio CVSS.

Due incidenti diversi mostrano lo stesso limite operativo della sicurezza infrastrutturale: il confine che dovrebbe separare una zona meno fidata dal sistema protetto può diventare esso stesso il punto di rottura. Docker ha corretto due vulnerabilità in Sandboxes, una delle quali permette a un guest malevolo su macOS di uscire dal workspace condiviso e raggiungere file dell’host. In Giappone, invece, la Digital Agency ha ricondotto un’intrusione nel Government Solution Service allo sfruttamento di una vulnerabilità su un apparato VPN, con circa 246.000 record personali potenzialmente coinvolti. In entrambi i casi il problema non riguarda un’applicazione periferica: colpisce direttamente il livello deputato all’isolamento o all’accesso.

Docker corregge due falle nel confine tra sandbox e host

Docker ha corretto in Sandboxes 0.42.0 le vulnerabilità CVE-2026-77179 e CVE-2026-79994, documentate nel security announcement ufficiale pubblicato da Docker. La prima, classificata Critical dal vendor, interessa il server virtio-fs utilizzato su macOS per condividere il workspace tra host e microVM. Quando il server riapriva un file precedentemente rimosso utilizzando un percorso memorizzato, poteva seguire un symlink sostituito dal guest: un processo malevolo poteva quindi rimpiazzare una directory padre con un collegamento simbolico, uscire dal workspace autorizzato e leggere o modificare file arbitrari con i privilegi dell’utente che esegue il VMM. Sono interessate le versioni da 0.28.0 fino alla 0.41.x. È un problema particolarmente delicato perché ricade nella stessa classe operativa delle falle che hanno già trasformato sandbox e hypervisor in percorsi verso l’host: quando il filesystem passthrough supera il perimetro previsto, il guest smette di essere realmente confinato.

Leggi anche: OpenAI non rivelò il wiki degli agenti: 18.000 messaggi e tecniche per uscire dalla sandbox

CVE-2026-79994 sfrutta una race condition nel relay dei socket Unix

La seconda falla, CVE-2026-79994, riguarda il relay guest-to-host utilizzato per collegarsi a socket Unix autorizzati. Docker controllava inizialmente che il pathname fosse interno al workspace, ma effettuava successivamente la connessione riutilizzando lo stesso percorso. Un guest malevolo poteva sostituire una directory intermedia con un symlink tra il controllo e l’utilizzo effettivo, sfruttando una condizione TOCTOU e inducendo l’host a collegarsi a un socket AF_UNIX esterno alla directory prevista. Il risultato può essere l’esposizione di dati o delle capacità offerte dal servizio raggiunto. La vulnerabilità riguarda le versioni da 0.37.0 fino a quelle precedenti alla 0.42.0. Le release note ufficiali di Docker Sandboxes 0.42.0 confermano la distribuzione della versione corretta il 7 settembre. Il problema si inserisce in una superficie d’attacco sempre più importante per i coding agent: filesystem, socket, proxy e integrazioni host-side contano almeno quanto il comportamento del modello, come mostrato anche dai recenti casi BragJack e Shai-Hulud negli assistenti AI e negli ambienti di sviluppo.

La microVM è il trust boundary, ma condivide comunque risorse decisive

Il punto più importante emerge dal modello di sicurezza ufficiale di Docker Sandboxes. L’agente dispone di privilegi elevati dentro la microVM: può usare sudo, installare pacchetti, utilizzare un Docker Engine privato ed eseguire codice. La microVM dovrebbe impedire l’accesso al resto dell’host, ma alcuni canali attraversano necessariamente il confine, compresi workspace, traffico di rete, credenziali mediate dal proxy, skill condivise e gateway MCP. In direct mode il workspace è addirittura montato in lettura e scrittura e le modifiche compaiono direttamente sull’host. Per questo Docker suggerisce, quando non è possibile aggiornare immediatamente, di utilizzare clone mode ed evitare mount host read-write aggiuntivi. Clone mode riduce il rischio di modifica del repository host, ma non impedisce all’agente di leggere tutti i file presenti nel repository montato in sola lettura, compresi eventuali .env. L’isolamento degli agenti resta quindi un sistema composto da più livelli, non una garanzia assoluta fornita dalla parola “sandbox”.

In Giappone una vulnerabilità VPN porta dentro il Government Solution Service

Il secondo caso sposta il problema dal confine locale tra VM e host al perimetro di rete di un’infrastruttura governativa. La Digital Agency giapponese ha comunicato ufficialmente che il 25 giugno 2026 è stato rilevato l’accesso a un elevato numero di file su un server attraverso l’account di un addetto alla manutenzione. L’indagine ha successivamente stabilito che un soggetto terzo aveva sfruttato una vulnerabilità su un dispositivo VPN per entrare nel sistema e condurre accessi non autorizzati.

Il 9 luglio l’account coinvolto è stato sospeso e le comunicazioni esterne dell’apparato compromesso sono state interrotte. La vicenda arriva pochi giorni dopo nuove RCE critiche nelle VPN Check Point e conferma perché i gateway di accesso remoto restino uno degli asset più sensibili dell’infrastruttura enterprise e pubblica: sono progettati per attraversare il confine che separa Internet dai sistemi interni.

Una vulnerabilità Medium può comunque produrre un incidente grave

Il dettaglio più significativo emerge dalla Q&A pubblicata dalla stessa Digital Agency: la vulnerabilità sfruttata era stata inizialmente valutata Medium secondo CVSS. L’agenzia non ha divulgato vendor, prodotto o CVE, spiegando che maggiori dettagli potrebbero interferire con le misure di sicurezza ancora in corso. Non è quindi possibile attribuire il caso a Check Point, Fortinet, SonicWall o ad altri produttori. Il dato Medium basta però a mostrare il limite di un vulnerability management governato meccanicamente dal punteggio. Un bug di media severità su un componente marginale non equivale allo stesso livello CVSS su un gateway che concentra autenticazione, accesso remoto e collegamenti verso reti governative. È lo stesso problema evidenziato dalle vulnerabilità Check Point finite nel ciclo di patching urgente di settembre: esposizione e posizione architetturale possono pesare più del numero assegnato alla CVE.

Circa 246.000 record possono essere usciti dal GSS

La Digital Agency ha individuato circa 246.000 record personali potenzialmente esposti. Il perimetro comprende circa 236.000 nomi, 231.000 indirizzi email, 94.000 numeri telefonici e circa 1.000 indirizzi fisici, con sovrapposizioni tra le categorie. Circa 189.000 record riguardano personale delle organizzazioni che utilizzano GSS e funzionari coinvolti nelle relative attività, mentre circa 57.000 fanno riferimento ad aziende e individui collegati ai lavori delle amministrazioni. Non risultano coinvolti My Number, coordinate bancarie o numeri pensionistici e, al momento della comunicazione, non erano stati confermati danni secondari. L’agenzia avverte però esplicitamente del rischio di email fraudolente, phishing, telefonate e SMS mirati, perché nomi, recapiti e relazione con la pubblica amministrazione offrono materiale sufficiente per costruire impersonazioni credibili. I precedenti sulle VPN Fortinet esposte in massa mostrano quanto le infrastrutture di accesso remoto possano trasformare rapidamente un problema tecnico in una superficie di abuso successiva.

Continua con:

• Akira ransomware riavvia Windows in Safe Mode per spegnere EDR e Defender
• OpenVPN 2.7.7 corregge sette CVE mentre Shelly 3.1.3 migliora AppImage e AUR

Il rischio operativo nasce dalla posizione del componente

Docker e Digital Agency descrivono vulnerabilità tecnicamente differenti, ma il loro valore operativo deriva dalla stessa caratteristica: colpiscono componenti che mediano l’accesso tra domini con livelli di fiducia differenti. Nel primo caso il guest dovrebbe restare dentro la microVM e il workspace consentito; nel secondo Internet dovrebbe fermarsi davanti al gateway VPN. Quando quel livello fallisce, una vulnerabilità apparentemente circoscritta può trasformarsi in accesso a file host, servizi locali o sistemi amministrativi interni. Le mitigazioni diventano quindi altrettanto architetturali: aggiornare Docker Sandboxes almeno alla 0.42.0, ridurre i mount read-write, usare clone mode dove possibile, e sulle infrastrutture VPN adottare una prioritizzazione del patching che consideri esposizione, privilegi, dati raggiungibili e funzione del dispositivo. Il CVSS resta utile, ma non può sostituire la conoscenza di ciò che si trova dietro la vulnerabilità.