Il 12 agosto 2026 il team di ricerca Imperva ha reso pubblica CVE-2026-17106, una falla nel comando docker cp che consente a un container malevolo di sovrascrivere file arbitrari sull'host e, su Linux, di ottenere esecuzione di codice come root. La vulnerabilità, battezzata CopyEscape, non richiede privilegi speciali nel container: basta che un utente esegua una copia routine per estrarre log o artefatti. L'impatto è massimo negli ambienti CI/CD e nelle sandbox AI-agent, dove la copia da container non fidati è operazione standard.
- CVE-2026-17106 colpisce
docker cpesbx cp(Docker Sandboxes) tramite una race condition TOCTOU nel flusso di creazione dell'archivio tar - Un processo malevolo nel container modifica un percorso tra due ispezioni consecutive del daemon, trasformando una directory in symlink che l'estrazione segue senza confinamento
- Su macOS l'estrazione avviene direttamente sul host, non nella VM Linux di Docker Desktop; su Linux con
sudo docker cpè possibile sovrascrivere/usr/bin/runcper ottenere root in un'operazione successiva - Le versioni patchate sono Docker Engine e CLI 29.7.2 o successivi, Docker Desktop 4.86.0 o successivi, Docker Sandboxes 0.38.0 rilasciato il 6 agosto 2026
Il meccanismo: due ispezioni, un percorso che cambia identità
Il nucleo della falla risiede in una race condition nel codice della libreria github.com/moby/go-archive v0.2.0, usata dal daemon Docker per creare l'archivio tar da trasferire al CLI. Il daemon ispeziona due volte lo stesso percorso nel filesystem del container: prima con WalkDir, poi con addTarFile che chiama Lstat. Tra queste due chiamate un processo nel container può modificare il percorso, trasformando una directory in un symlink.
L'estrazione da parte del Docker CLI segue il symlink senza validare adeguatamente il target, permettendo la scrittura di file al di fuori della directory destinazione. Il risultato è che l'archivio tar descrive due filesystem diversi nello stesso momento: contiene una entry symlink per il percorso 'escape' e contemporaneamente una entry child sotto di esso come se 'escape' fosse ancora una directory.
Il proof of concept sviluppato da Imperva utilizza LD_PRELOAD per intercettare gli accessi al filesystem: un interposer fa apparire /watched/file.txt come file regolare ai processi nel container, mentre il daemon vede una directory. Il container usa notifiche filesystem per sincronizzare la race condition: un file grande prima della directory pivot viene monitorato, e quando il daemon lo apre l'attaccante sa quando eseguire i due rename necessari.
Da scrittura arbitraria a root: la catena su Linux
Su Linux la combinazione con privilegi elevati rende la falla particolarmente grave. Imperva ha validato l'exploit sulla versione 29.6.1: con sudo docker cp è possibile sovrascrivere /usr/bin/runc, il runtime container di Docker. La sostituzione con uno shell script permette di ottenere esecuzione di codice come root in un'operazione Docker successiva.
"The exploit did not obtain root from the Docker daemon. The copy already had enough authority to replace runc, and the later execution converted that file write into root code execution"
Questa distinzione è tecnica ma fondamentale: la vulnerabilità non concede privilegi root direttamente dal daemon, ma sfrutta i permessi già posseduti dal processo che esegue docker cp. Se quell'utente è root o ha accesso a sudo, la scrittura su file di sistema diventa escalation completa.
Il rischio nascosto di macOS e le sandbox AI
Su macOS la superficie di attacco è meno intuitiva ma altrettanto seria. Contrariamente a quanto molti sviluppatori assumono, l'estrazione di docker cp avviene direttamente sul host Mac, non nella VM Linux di Docker Desktop. Imperva ha validato l'exploit sulla versione 4.81.0 (build 232925): un container malevolo può sovrascrivere file dell'utente nel filesystem macOS, con potenziali effetti a cascata su applicazioni e configurazioni di sistema.
L'angolo di attacco più preoccupante riguarda gli ambienti dove la copia da container è automatizzata. Le pipeline CI/CD estraggono regolarmente artefatti di build, log di test o report di coverage da container effimeri. Le sandbox AI-agent isolano codice generato da modelli linguistici in container temporanei, poi ne estraggono output o file di lavoro. In entrambi i casi, il container di origine non è implicitamente fidato: può contenere codice generato automaticamente o dipendenze non verificate.
Secondo la ricerca di Imperva riportata da GBHackers, "the potential impact is significant for developer systems, CI/CD infrastructure, incident response workflows, and AI-agent sandbox environments". La frase riassume la natura insidiosa della falla: non colpisce una configurazione esotica, ma un'operazione quotidiana eseguita milioni di volte al giorno.
Cosa fare adesso
Le azioni prioritarie derivano direttamente dalle versioni patchate documentate nella ricerca. Docker Engine e CLI richiedono l'aggiornamento alla versione 29.7.2 o successivi. Docker Desktop va portato alla versione 4.86.0 o successivi. Per chi utilizza Docker Sandboxes, la versione 0.38.0 rilasciata il 6 agosto 2026 corregge sbx cp per la stessa CVE.
Nei sistemi dove l'aggiornamento immediato non è praticabile, la mitigazione passa per la revisione dei flussi che eseguono docker cp da container non fidati. Le pipeline CI/CD devono limitare l'operazione a container con immagini verificate e digest noti; le sandbox AI-agent richiedono verifica dell'output estratto prima dell'esecuzione su host con privilegi elevati.
Lo strumento Trivy, citato nelle fonti come strumento di scanning di vulnerabilità container, può integrarsi nei flussi di build per rilevare componenti vulnerabili nelle immagini prima del deploy. La sua efficacia specifica su CVE-2026-17106 non è documentata nel brief, ma il suo ruolo nel panorama degli strumenti di sicurezza container è confermato dal vendor Aqua Security.
Il brief non documenta misure correttive specifiche oltre al patching, né raccomandazioni operative dettagliate per la rotazione di credenziali o la segmentazione di rete. La fonte non specifica la natura dei dati esposti oltre ai file di sistema sovrascrivibili.
Perché CopyEscape cambia il modo di pensare ai container
La lezione di CopyEscape va oltre il singolo CVE. Per anni il modello di sicurezza Docker ha enfatizzato la separazione tra container e host: namespaces, cgroups, capabilities. La falla dimostra che i confini si dissolvono nel momento in cui si autorizza un'interazione diretta, anche apparentemente innocua come la copia di un file.
Il comando che ha originato la ricerca, come riporta il blog di Imperva, "could hardly look more ordinary: docker cp container:/path/to/file.txt ./file.txt". È proprio questa quotidianità a rendere la vulnerabilità pericolosa: non richiede una configurazione errata o un privilegio speciale, ma una routine condivisa da sviluppatori, operatori di sicurezza e sistemi automatizzati.
La data di scoperta precisa non è attestata nelle fonti disponibili; la pubblicazione è del 12 agosto 2026. Non emergono sovrapposizioni infrastrutturali che colleghino l'attività a campagne note allo stato attuale, né conferme di exploit in-the-wild. Il punteggio CVSS non è esplicitato in nessuna fonte disponibile.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://gbhackers.com/docker-copyescape-vulnerability/
- https://teamwin.in/copyescape-docker-vulnerability-lets-malicious-containers-overwrite-host-files-and-gain-root/
- https://aquasecurity.github.io/trivy/
- https://gbhackers.com/docker-compose-flaw/
- https://gbhackers.com/pam-backdoor-targets-linux-systems/
- https://www.imperva.com/blog/copyescape-taking-over-docker-hosts-with-docker-cp/