CVE-2026-17106 CopyEscape: vulnerabilita docker cp

“`html

Una nuova vulnerabilità critica sta mettendo in allarme chi lavora quotidianamente con container Docker. Si chiama CVE-2026-17106, conosciuta anche con il nome in codice “CopyEscape”, ed è stata scoperta dall’Imperva Red Team. Il problema riguarda il comando docker cp (e il suo equivalente sbx cp nelle Docker Sandboxes) e può permettere a un container malevolo di scrivere file al di fuori della destinazione prevista sul sistema host. In alcuni scenari Linux, questo può addirittura portare a un’escalation di privilegi fino a root.

In questo articolo vediamo come funziona questa vulnerabilità, quali sono gli scenari di rischio più concreti e, soprattutto, come proteggersi subito.

Cos’è CVE-2026-17106 (CopyEscape)

CopyEscape sfrutta una combinazione di fattori tecnici che, messi insieme, permettono di aggirare i controlli di sicurezza previsti durante l’operazione di copia file da un container verso l’host. In sintesi, il problema nasce da:

• Una pipeline di creazione ed estrazione di archivi tar che avviene tra il daemon Docker e il client.
• Una mancata corrispondenza tra il percorso file che viene verificato dai controlli di sicurezza e quello effettivamente usato durante la scrittura su disco.
• Una race condition, in cui il container sostituisce una directory con un symlink che punta fuori dalla destinazione prevista, proprio nel momento in cui avviene la copia.

Il risultato? Un container compromesso o volutamente malevolo può forzare la scrittura di file sensibili sull’host, aprendo la strada a persistenza, furto di credenziali o, nei casi peggiori, escalation a root.

Come funziona tecnicamente l’attacco

Per capire la portata del problema, è utile guardare al meccanismo che sta dietro docker cp, senza entrare nei dettagli di un exploit vero e proprio.

La pipeline tar tra daemon e client

Quando si esegue docker cp, il daemon Docker analizza il filesystem del container e genera uno stream in formato tar, che descrive file, directory e symlink. Questo stream viene poi trasmesso al client (la CLI di Docker), che si occupa di estrarlo nella cartella di destinazione sull’host.

Il problema della validazione dei path

Il codice che gestisce questa operazione effettua dei controlli per evitare che i file vengano scritti fuori dalla cartella di destinazione (ad esempio bloccando tentativi di path traversal con ../). Il problema è che questi controlli vengono eseguiti su una versione del percorso che non corrisponde esattamente a quella usata realmente al momento della scrittura del file.

La race condition con i symlink

Qui entra in gioco la parte più insidiosa della vulnerabilità. Un processo interno al container può, in un momento preciso della sequenza di copia, sostituire una directory con un symlink che punta a un percorso esterno alla destinazione. Se il controllo di sicurezza viene fatto su una versione del path e la scrittura effettiva segue invece il nuovo symlink, il file finisce scritto in un punto del filesystem host completamente diverso da quello previsto.

Quando l’attacco può realmente verificarsi

Perché CopyEscape possa essere sfruttata, servono alcune condizioni specifiche:

• Un container in esecuzione dove un processo malevolo può modificare in modo sincronizzato (rename o link) directory e symlink.
• Un operatore o un processo automatizzato che esegue docker cp (o sbx cp) verso quel container, copiando file dal container verso l’host.
• Privilegi elevati dell’operatore: più alto è il livello di privilegio con cui viene eseguito docker cp, maggiore è il potenziale danno.
• Un corretto sincronismo temporale tra le azioni malevole nel container e la sequenza di creazione/estrazione dell’archivio tar.

Scenari di impatto concreti

Gli effetti di questa vulnerabilità cambiano a seconda del contesto in cui viene sfruttata.

macOS e workstation

Su un ambiente desktop, l’attacco può portare alla sovrascrittura di file critici dell’utente, come script di avvio, configurazioni SSH, LaunchAgents o profili shell. Questo apre la strada a persistenza sul sistema o al furto di credenziali. Anche chi lavora in ambito forense, estraendo artefatti da un container sospetto, rischia inconsapevolmente di installare backdoor sul proprio computer.

Server Linux

In ambito server la situazione è ancora più delicata. Se docker cp viene eseguito con privilegi elevati, un attaccante potrebbe sovrascrivere binari di sistema o script eseguiti automaticamente da altri servizi, incluso in alcuni casi runtime come runc. Il rischio concreto è un’escalation di privilegi fino a root. Allo stesso modo, file di configurazione sensibili come quelli SSH, cron o systemd possono diventare bersaglio per ottenere persistenza sul sistema.

Pipeline CI/CD e automazioni

Le pipeline automatizzate che raccolgono log o artefatti da container in esecuzione, senza fermarli prima, rappresentano un vettore di attacco particolarmente esposto. Automatizzare la copia significa spesso eseguire operazioni con permessi elevati, senza il controllo manuale che un operatore umano potrebbe applicare.

Ambienti AI-agent e sandbox

La stessa logica di attacco colpisce anche i comandi di copia usati nelle Docker Sandboxes, pensate per agenti AI. Un agente compromesso o malevolo potrebbe sfruttare gli artefatti di output per attaccare l’host o l’infrastruttura che ospita la sandbox stessa.

Il paradosso operativo di CopyEscape

C’è un aspetto particolarmente ironico in questa vulnerabilità: l’azione compiuta per raccogliere prove da un container sospetto, ad esempio in un’indagine forense, è proprio quella che può innescare la fuga dal container stesso. Lo stesso vale per chi recupera output da agenti AI: estrarre artefatti può trasferire il danno direttamente sull’host.

Gli analisti di sicurezza e gli strumenti automatici sono quindi particolarmente esposti, perché spesso operano con permessi elevati o su container ancora in esecuzione, senza metterli in pausa prima dell’operazione di copia.

Patch ufficiali e mitigazioni

La prima linea di difesa resta, come sempre, l’aggiornamento tempestivo. Le versioni corrette sono:

• Docker Engine/CLI: 29.7.2 o successivo
• Docker Desktop: 4.86.0 o successivo
• Docker Sandboxes: 0.38.0 o successivo

È sempre consigliabile verificare gli annunci di sicurezza ufficiali e i changelog forniti direttamente da Docker.

Mitigazioni temporanee

In attesa di aggiornare, o come pratica di hardening aggiuntiva, si possono adottare queste contromisure:

• Evitare di eseguire docker cp (o sbx cp) su container non affidabili o sospetti.
• Non eseguire docker cp con privilegi elevati (come sudo) sull’host, riducendo i permessi operativi dove possibile.
• Fermare il container con docker stop prima di effettuare la copia: questo elimina la possibilità che un processo interno modifichi il filesystem durante l’operazione (anche se non sempre è praticabile).
• Valutare metodi alternativi per ottenere artefatti, evitando l’estrazione tar diretta da container in esecuzione.
• Applicare il principio del least privilege, limitando chi può comunicare con il daemon Docker e chi può usare comandi di copia o archiviazione.
• Monitorare e loggare le esecuzioni di docker cp, segnalando come possibili indicatori di compromissione copie ripetute o sospette da container non fidati.
• Aggiornare immagini e pipeline CI/CD che automatizzano operazioni di copia, assicurandosi che utilizzino versioni patchate.

Hardening aggiuntivo

Per chi gestisce ambienti particolarmente sensibili, è utile anche:

• Disabilitare l’accesso non necessario alle API di archiviazione nei deployment gestiti.
• Utilizzare forme di isolamento più forte, come macchine virtuali dedicate, quando si devono estrarre artefatti da workload non fidati.

Come verificare la propria esposizione

Alcuni controlli pratici per capire se si è a rischio:

• Verificare la versione installata con il comando docker version, controllando sia Engine/CLI che Docker Desktop.
• Analizzare i log di amministrazione e delle pipeline CI alla ricerca di esecuzioni recenti di docker cp o sbx cp.
• Verificare la presenza di file modificati in directory critiche subito dopo operazioni di copia da container in esecuzione.
• Controllare eventuali attività sospette di rinomina o creazione di symlink all’interno dei container, in concomitanza con operazioni di copia esterne.

La lezione di fondo

CopyEscape ci ricorda un principio fondamentale della sicurezza informatica: l’estrazione di archivi non è mai un confine di fiducia sicuro di per sé. I controlli basati solo su normalizzazione delle stringhe di percorso possono essere aggirati facilmente in presenza di symlink e modifiche concorrenti al filesystem.

Questo principio va oltre Docker e si applica a qualsiasi sistema che estrae archivi provenienti da zone non fidate verso zone di fiducia. Bisogna sempre considerare:

• Il classico problema del TOCTOU (time-of-check vs time-of-use), causato da modifiche concorrenti al filesystem.
• Il comportamento dei symlink durante l’estrazione (seguirli o meno).
• L’utilizzo di API sicure come open O_NOFOLLOW, canonicalizzazione tramite openat e restrizioni sul dirfd.
• L’importanza dell’atomicità durante tutto il processo di estrazione.

In pratica, non basta affidarsi a una lista nera di percorsi o a semplici normalizzazioni. Servono controlli a livello di I/O e, quando possibile, eseguire l’estrazione in ambienti isolati e non privilegiati, verificando sempre il contenuto prima di spostarlo in produzione o in percorsi sensibili.

Conclusione

CVE-2026-17106, alias CopyEscape, dimostra ancora una volta quanto sia delicato il confine tra container e host, soprattutto quando si tratta di operazioni apparentemente semplici come una copia di file. La combinazione di pipeline tar, validazione imperfetta dei path e race condition con symlink può trasformare un comando di routine come docker cp in un vettore di attacco serio, capace in certi scenari di portare fino alla escalation a root su sistemi Linux.

La buona notizia è che le patch ufficiali sono già disponibili: aggiornare a Docker Engine/CLI 29.7.2, Docker Desktop 4.86.0 e Docker Sandboxes 0.38.0 risolve il problema alla radice. Nel frattempo, adottare le mitigazioni consigliate, monitorare i log e applicare il principio del least privilege sono passi fondamentali per ridurre il rischio, specialmente per chi lavora quotidianamente con container in ambienti di produzione, CI/CD o forensics.

“`