CopyEscape: un semplice docker cp apre alla fuga dai container

Il comando docker cp, usato milioni di volte al giorno per estrarre log o artefatti dai container, nasconde una falla che inverte la relazione di fiducia tra host e ospite. Il 12 agosto 2026 le fonti di settore confermano i dettagli di CVE-2026-17106, battezzata CopyEscape: una race condition nel flusso tar di Docker permette a un container compromesso di riscrivere file arbitrari sul filesystem dell'host, con possibile escalation a root quando il comando viene eseguito con privilegi elevati. La vulnerabilità, scoperta dall'Imperva Red Team, trasforma operazioni forensi di routine — copiare un sospetto file di log — in vettori di attacco.

Il comando innocuo che rompe il confine

L'Imperva Red Team ha aperto la ricerca con una riga banale: docker cp container:/path/to/file.txt ./file.txt. Quel comando, come ha documentato il team, è il punto di partenza di un attacco che rovescia l'architettura di sicurezza di Docker. Il problema non sta nel daemon, che gira tipicamente con privilegi elevati, ma nel client CLI e nella libreria github.com/moby/go-archive v0.2.0.

La pipeline di docker cp non trasferisce file direttamente: il daemon serializza il contenuto del container in un archivio tar, e il client lo deserializza sulla macchina locale. Questa separazione tra chi costruisce l'archivio (il container, sotto controllo dell'attaccante) e chi lo estrae (il client, con i permessi dell'utente che ha lanciato il comando) è il cuore del problema.

Ron Masas di Imperva, citato da CyberPress, ha sintetizzato il meccanismo: un processo nel container malevolo può alterare un pathname mentre Docker costruisce l'archivio. La race condition sfrutta lo scarto temporale tra la verifica del percorso e la sua effettiva creazione sul filesystem di destinazione.

"The attacker controls the container and its files, the CLI supplies access to the host filesystem" — Imperva Red Team

Come funziona la race condition nel dettaglio

Il codice sorgente analizzato da Imperva mostra un pattern classico di time-of-check to time-of-use. Il walker che esplora il filesystem del container registra inizialmente un percorso come directory valida. Tra quella registrazione e la successiva chiamata a addTarFile, che costruisce l'header dell'archivio tar, un processo nel container sostituisce quella directory con un symlink. Il risultato è un archivio tar che contiene entrambe le rappresentazioni: quella originale, verificata, e quella manipolata.

Al momento dell'estrazione, il client CLI costruisce un percorso di destinazione e ne verifica la validità, ma poi crea il symlink usando il valore originale presente nell'archivio. Il path controllato e il path effettivamente scritto divergono. L'estrattore, convinto di operare all'interno della directory autorizzata, segue invece il symlink piazzato dall'attaccante verso qualsiasi punto del filesystem.

Su macOS la conseguenza è particolarmente insidiosa: il client Docker Desktop estrae i file direttamente sul filesystem nativo dell'host, non nella VM Linux dove gira il daemon. Un utente che copia un log sospetto per analizzarlo in locale potrebbe trovarsi con file di sistema sovrascritti nella sua home directory.

Da sovrascrittura a root: la catena su Linux

La proof-of-concept validata da Imperva su Docker Engine 29.6.1 (Linux) e Docker Desktop 4.81.0 (macOS) dimostra che la sovrascrittura arbitraria è solo il primo gradino. Su sistemi Linux dove docker cp viene eseguito con sudo, l'attaccante può puntare direttamente a /usr/bin/runc, il runtime di container sottostante a Docker.

La PoC sostituisce il binario runc con uno script controllato dall'attaccante. Quando un'operazione Docker successiva — anche banale come l'avvio di un nuovo container — invoca runc, esegue il binario compromesso con privilegi di root. L'Imperva Red Team ha sottolineato un punto tecnico cruciale: l'exploit non ottiene root dal daemon Docker. La copia dispone già dell'autorità sufficiente per riscrivere runc; è l'esecuzione successiva a convertire quella capacità di scrittura in esecuzione di codice come root.

"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" — Imperva Red Team

Questa distinzione ha conseguenze pratiche significative: non serve compromettere il daemon, già protetto da meccanismi di isolamento; basta che un amministratore esegua sudo docker cp da un container che non sa essere malevolo. In pipeline CI/CD automatizzate, dove script senza intervento umano eseguono regolarmente questa operazione, la finestra di esposizione è massima.

La trappola forense e il rischio delle sandbox AI

L'articolo di Imperva esplora uno scenario che rasenta l'ironia amara: un analista di sicurezza che cerca di indagare su un container sospetto copiandone i log diventa inconsapevolmente il veicolo della propria compromissione. L'operazione forense standard — estrarre evidenze per analisi offline — attiva il payload. Il container non deve comunicare con l'esterno, non richiede exploit di rete: la fuga avviene attraverso il canale di estrazione dati aperto dall'investigatore.

Il rischio si estende a un settore in rapida espansione. Docker Sandboxes, la piattaforma per eseguire agenti AI in ambienti isolati, condivide la stessa logica di copia con il comando sbx cp. La versione 0.38.0 di Sandboxes, rilasciata il 6 agosto 2026, corregge esplicitamente la stessa "destination-escape flaw in sbx cp copy-out" sotto CVE-2026-17106. In ambienti dove coding agent generano ed eseguono codice automaticamente, la possibilità che un artefatto malevolo esca dalla sandbox attraverso una routine copia-incolla è una superficie d'attacco con profili di rischio ancora in definizione.

Cosa fare adesso

• Aggiornare immediatamente Docker Engine/CLI alla versione 29.7.2, Docker Desktop alla 4.86.0 e Docker Sandboxes alla 0.38.0, secondo quanto rilasciato dal vendor.
• Verificare l'uso di sudo negli script e nelle procedure che eseguono docker cp: l'esecuzione con privilegi elevati è condizione necessaria per l'escalation a root su Linux.
• Rivedere le pipeline CI/CD che automatizzano l'estrazione di artefatti dai container: sostituire docker cp con meccanismi di esportazione che non passano per la deserializzazione tar del client, dove possibile.
• Ispezionare i log di sistema per esecuzioni di docker cp su container non trusted, specialmente in ambienti forensi dove il container sorgente è già sospetto.

Il disclosure di CopyEscape è iniziato in aprile 2026 e ha attraversato multiple estensioni, secondo CyberSecurityNews, per risolvere regressioni nelle patch candidate. Questo ritardo nella stabilizzazione della correzione suggerisce che il componente go-archive abbia implicazioni più ampie della singola CVE documentata, anche se il dossier non specifica se altri comandi Docker che dipendono dalla stessa libreria siano affetti.

FAQ

Basta un container compromesso per essere vulnerabili?

Sì: il container deve essere sotto controllo dell'attaccante, ma non richiede privilegi speciali all'interno del container stesso. La vulnerabilità sfrutta il disallineamento tra chi costruisce l'archivio (il container) e chi lo estrae (il client).

Il mio Docker Desktop su Mac è a rischio anche senza sudo?

Sì: su macOS l'estrazione avviene direttamente sul filesystem host. Non serve sudo per sovrascrivere file nella home directory dell'utente, sebbene l'escalation a root richieda comunque condizioni aggiuntive non dettagliate nel dossier.

Perché il CVE record è ancora riservato?

Il record CVE-2026-17106 risulta in stato reserved su cve.org al momento della pubblicazione. Il CVSS score e i dettagli completi della CNA non sono ancora popolati, anche se l'identificatore è confermato dalle fonti primarie.

L'architettura di Docker ha sempre presupposto che il daemon fosse il perimetro da difendere, relegando il client a ruolo passivo. CopyEscape dimostra che la catena di fiducia si rompe altrove: nel momento in cui un archivio tar attraversa il confine, chi estrae diventa vulnerabile a chi ha costruito. Per forensi, sviluppatori e operatori di sandbox AI, la lezione è che nessun comando è troppo banale per essere esaminato con sospetto.

Fonti

• https://cybersecuritynews.com/copyescape-docker-vulnerability/
• https://www.imperva.com/blog/copyescape-taking-over-docker-hosts-with-docker-cp/
• https://gbhackers.com/docker-copyescape-vulnerability/
• https://teamwin.in/copyescape-docker-vulnerability-lets-malicious-containers-overwrite-host-files-and-gain-root/
• https://cyberpress.org/copyescape-docker-flaw/?amp
• https://gbhackers.com/docker-copyescape-vulnerability/amp/
• https://www.cve.org/CVERecord?id=CVE-2026-17106
• https://aquasecurity.github.io/trivy/
• https://github.com/moby/go-archive/security/advisories/GHSA-hfg8-hc9c-6c3h