Docker Desktop ECI: LPE 8.8 consente escape dai container
Una falla nel componente Enhanced Container Isolation di Docker Desktop permette escalation locale con CVSS 8.8. La patch è nella versione 4.59.0.
Contenuto
Docker Desktop presenta una vulnerabilità di escalation dei privilegi locale nel componente Enhanced Container Isolation, con punteggio CVSS 8.8. La falla, resa pubblica il 23 aprile 2026 nell'advisory ZDI-26-299, consente a un attaccante con accesso containerizzato a basso privilegio di aggirare i confini di sicurezza e compromettere risorse protette. Per gli sviluppatori e i team DevOps che usano l'isolamento rafforzato come barriera tra container e workstation, la notizia smonta un presupposto fondamentale: il livello "enhanced" non basta se una singola funzione esposta nel processing CLI lascia uno spiraglio.
- La vulnerabilità risiede nel processing degli argomenti Docker CLI, dove una "exposed dangerous function" consente l'escape dai confini del container.
- L'attaccante deve già disporre della capacità di eseguire codice a basso privilegio all'interno di un container: non è un attacco da remoto, ma una escalation post-compromissione.
- Il vettore CVSS AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H indica impatto massimo su riservatezza, integrità e disponibilità, con scope changed per effetti oltre il componente vulnerabile.
- La correzione è disponibile in Docker Desktop 4.59.0, rilasciata dopo oltre tre mesi dalla segnalazione iniziale del ricercatore Nitesh Surana.
Come funziona la falla nel processing CLI
L'advisory ZDI-26-299 identifica il problema nel modo più tecnico possibile: "The specific flaw exists within the processing of Docker CLI arguments. The issue results from an exposed dangerous function." La formulazione, per quanto sintetica, dice molto su dove si annida il rischio. Non si tratta di un bug nel runtime containerizzato in senso stretto, né di una debolezza nel kernel Linux sottostante, ma di una funzione pericolosa lasciata accessibile durante la gestione degli argomenti passati alla riga di comando Docker.
Questa collocazione è rilevante per due ragioni. Primo: il processing CLI avviene in un punto di confine tra l'utente e il sistema, dove i dati in ingresso sono per definizione meno affidabili. Secondo: Enhanced Container Isolation (ECI) è stato introdotto proprio per creare un perimetro sicuro intorno a questi punti di contatto. Una funzione esposta in quel processing significa che il perimetro ha un varco strutturale, non un errore di configurazione sanabile con una regola in più.
Il meccanismo preciso di sfruttamento non è dettagliato nell'advisory, e non sono disponibili codici proof-of-concept. Ciò che si sa è che l'attaccante, una volta dentro un container con privilegi limitati, può interagire con questa funzione per scalare privilegi. L'ambito "Scope Changed" nel vettore CVSS (S:C) suggerisce che l'impatto travalica il componente direttamente vulnerabile, toccando risorse normalmente protette dall'isolamento.
Chi è a rischio e quali sono le condizioni di attacco
La condizione necessaria per sfruttare la falla è precisa e vincolante: "An attacker must first obtain the ability to execute low-privileged code within a container in order to exploit this vulnerability." Questo esclude gli attacchi da remoto non autenticati, ma non rende la minaccia trascurabile. Nelle pipeline di sviluppo moderne, un container a basso privilegio è spesso il punto di partenza naturale per un attaccante che ha compromesso un'immagine, iniettato codice malevolo in una dipendenza, o sfruttato un'applicazione vulnerabile in esecuzione nel container.
L'ambiente tipicamente esposto è quello delle workstation degli sviluppatori, dove Docker Desktop gira con accesso privilegiato alla macchina host per gestire container, volumi e rete. Se ECI fallisce, l'attaccante può interagire con il filesystem host, accedere a credenziali, codice sorgente, chiavi SSH e altri secret di sviluppo. La stessa architettura che rende Docker Desktop comodo — integrazione nativa con il sistema operativo, condivisione di file, forwarding di porte — diventa un moltiplicatore di impatto quando il confine di isolamento crolla.
Il profilo di rischio cambia se si considera l'uso di Docker Desktop in contesti enterprise con policy rigide. Dove ECI era richiesto esplicitamente come controllo di sicurezza, la falla rende quel controllo inaffidabile fino all'applicazione della patch. Non è noto se esistano workaround temporanei oltre all'aggiornamento: l'advisory non ne menziona.
La timeline dalla segnalazione alla pubblicazione
Nitesh Surana, ricercatore di Trend Research, ha inviato la segnalazione a Docker il 9 gennaio 2026. La pubblicazione coordinata dell'advisory ZDI-26-299 è avvenuta il 23 aprile 2026, dopo più di tre mesi di embargo. Questo intervallo è compatibile con la complessità di una correzione che tocca il processing CLI di un prodotto ampiamente diffuso tra gli sviluppatori, ma non ci sono informazioni pubbliche sul contenuto delle comunicazioni tra ricercatore e vendor durante quel periodo.
La versione corretta, 4.59.0, è indicata nell'advisory come fix disponibile. Non è chiaro se il rilascio sia avvenuto contestualmente alla pubblicazione: gli utenti devono verificare la disponibilità effettiva del pacchetto per il proprio sistema operativo. La mancanza di un identificativo CVE nell'advisory al momento della pubblicazione lascia aperta la questione della tracciabilità formale nei sistemi di gestione delle patch aziendali.
"Fixed in Docker Desktop 4.59.0" — Advisory ZDI-26-299, Zero Day Initiative
Cosa fare adesso
- Verificare la versione installata di Docker Desktop e pianificare l'aggiornamento a 4.59.0 o superiore. In ambienti gestiti, coordinare con il team IT la distribuzione prioritaria della patch.
- Rivedere le policy di utilizzo di ECI fino all'applicazione del fix: se l'isolamento rafforzato era considerato sufficiente per proteggere dati sensibili, valutare misure compensative come l'esecuzione di container non attendibili su ambienti separati o virtualizzati più rigidi.
- Controllare i container in esecuzione con privilegi ridotti ma con accesso a risorse critiche: la vulnerabilità richiede codice a basso privilegio come prerequisito, quindi la superficie di attacco si restringe ma non si annulla dove esistono container con accesso a secret o rete interna.
- Monitorare l'eventuale assegnazione di un CVE e l'aggiornamento dell'advisory ZDI con dettagli tecnici aggiuntivi, inclusa eventuale pubblicazione di PoC che potrebbe accelerare la creazione di exploit funzionanti.
Perché questa falla mette in discussione il modello di confidenza
ECI è stato introdotto come risposta a un problema reale: gli sviluppatori usano container da fonti non verificabili, e il modello di sicurezza tradizionale di Docker Desktop lasciava troppa superficie esposta alla macchina host. La vulnerabilità ZDI-26-299 dimostra che anche architetture con queste ambizioni possono cedere in punti imprevisti, dove il codice di interfaccia — in questo caso il processing CLI — assume compiti troppo sensibili senza sufficiente hardening.
Per l'industria, il caso solleva interrogativi più ampi. Quanto è auditabile il percorso tra input CLI e esecuzione privilegiata in strumenti di sviluppo integrati? E quanto la comodità di un'interfaccia unificata tra host e container espone a rischi sistemici quando quell'interfaccia contiene funzioni pericolose non sufficientemente isolate? Docker Desktop 4.59.0 chiude questa specifica falla, ma la domanda sulla robustezza del processing CLI come superficie d'attacco rimane aperta per chiunque costruisca sandbox con promesse simili.
FAQ
La vulnerabilità interessa anche Docker Engine su server Linux?
No. L'advisory si riferisce specificamente a Docker Desktop, il prodotto per workstation, e al suo componente Enhanced Container Isolation. Docker Engine in esecuzione su server Linux non è citato come affetto.
È necessario disabilitare ECI come misura temporanea?
L'advisory non menziona workaround o la necessità di disabilitare ECI. L'aggiornamento a 4.59.0 è indicato come fix. Dove la patch non è immediatamente applicabile, valutare misure compensative in base al proprio profilo di rischio.
Esistono exploit pubblici o segnalazioni di attacchi attivi?
Non risultano dall'advisory ZDI-26-299 né dalle fonti disponibili. La mancanza di dettagli tecnici e di PoC pubblici riduce al momento la probabilità di sfruttamento di massa, ma non la esclude in futuro.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.