Una vulnerabilidad de Docker recién revelada, rastreada como CVE-2026-17106 y apodada "CopyEscape", permite que contenedores maliciosos sobrescriban archivos en la máquina host y, en ciertas configuraciones, logren la ejecución completa de código como root.

El fallo fue descubierto por el Red Team de Imperva y afecta al comando docker cp, ampliamente utilizado, junto con el comando relacionado sbx cp empleado en los Docker Sandboxes para flujos de trabajo de agentes de IA.

Si se explota, CopyEscape permite que un contenedor malicioso escape de su entorno aislado, escriba o sobrescriba archivos arbitrarios en el host cliente y, bajo condiciones específicas en Linux, logre la ejecución de código a nivel de root.

La vulnerabilidad CopyEscape de Docker permite el acceso root

La vulnerabilidad reside dentro del pipeline de archivos de Docker, el mecanismo que mueve archivos entre un contenedor y la máquina host. Cuando ejecutas un comando simple como docker cp contenedor:/ruta/al/archivo.txt ./archivo.txt, Docker no realiza una copia directa del sistema de archivos.

En su lugar, el daemon recorre el sistema de archivos activo del contenedor, empaqueta la ruta seleccionada en un archivo tar y entrega ese archivo a la CLI de Docker para su extracción en la máquina local.

Este diseño asume dos cosas: que el daemon produce un archivo consistente y que la CLI mantiene cada archivo extraído dentro del destino que tú elegiste. Los investigadores de Imperva encontraron una forma de romper ambas suposiciones en una sola operación de copia.

El exploit encadena una condición de carrera (race condition) del sistema de archivos con una comprobación de enlaces simbólicos (symlinks) defectuosa. Debido a que Docker bloquea solo su estado interno durante el recorrido del archivo y no los procesos que se ejecutan dentro del contenedor, un atacante puede manipular los archivos a mitad del escaneo.

Utilizando una secuencia temporizada de intercambios de directorios, el contenedor malicioso engaña al rastreador de Docker para que registre un directorio y luego lo reemplace silenciosamente por un enlace simbólico que apunte fuera del destino previsto, como /usr/bin.

Una comprobación de validación en el código de extracción de Docker inspecciona una ruta construida, pero en realidad crea un symlink utilizando una ruta diferente y no comprobada del archivo. Esa discrepancia permite que los archivos del atacante aterricen donde sea que apunte el enlace simbólico, saltándose completamente el sandbox.

Dado que docker cp sustenta tareas rutinarias como la recopilación de artefactos de compilación, registros y evidencia forense, la vulnerabilidad amenaza directamente a los pipelines de CI/CD, las estaciones de trabajo de los desarrolladores y los flujos de trabajo de respuesta a incidentes. Irónicamente, un analista que extraiga evidencia de un contenedor comprometido para investigarlo podría activar el exploit sin saberlo.

En macOS, donde Docker Desktop ejecuta su daemon dentro de una máquina virtual, la CLI sigue extrayendo archivos localmente, lo que significa que los atacantes podrían sobrescribir scripts de inicio de shell, configuraciones de SSH o LaunchAgents para lograr la ejecución de código la próxima vez que abras una terminal.

En Linux, si docker cp se ejecuta con privilegios elevados, como es común en la automatización, la misma primitiva de escritura puede reemplazar binarios del sistema como runc, convirtiendo la sobrescritura de un archivo en un acceso root inmediato.

Los investigadores también confirmaron que el fallo afecta al comando sbx cp de los Docker Sandboxes, exponiendo los entornos de agentes de codificación de IA al mismo riesgo de escape de destino al recuperar archivos de sandboxes no confiables.

Docker ha parcheado el problema en Docker Engine y CLI 29.7.2, Docker Desktop 4.86.0 y Docker Sandboxes 0.38.0, tras un proceso de divulgación que comenzó en abril de 2026 y requirió múltiples extensiones para resolver regresiones de una corrección anterior.

Si tu organización no puede actualizar inmediatamente, deberías evitar ejecutar docker cp contra contenedores no confiables o activos, detener los contenedores antes de copiar archivos, eliminar el uso de sudo docker cp y recuperar datos sospechosos solo a través de entornos aislados y desechables.

La lección fundamental es que la extracción de archivos es en sí misma un límite de seguridad, uno que las comprobaciones de cadenas de rutas no pueden garantizar una vez que entran en juego los enlaces simbólicos y los cambios de archivos concurrentes.