Docker emitió una alerta de seguridad el 15 de septiembre sobre una vulnerabilidad crítica en Docker Sandboxes para macOS que permite que código malicioso ejecutado dentro de la máquina virtual escape del directorio del proyecto compartido y lea o modifique archivos en cualquier otra ubicación del host. La falla, identificada como CVE-2026-77179, tiene una calificación crítica y afecta a las versiones 0.28.0 hasta la 0.42.0 (excluyendo esta última) en macOS. Fue corregida en la versión 0.42.0, publicada el 7 de septiembre.
Detalles de la vulnerabilidad
Docker Sandboxes ejecuta cada agente de codificación de IA en su propia máquina virtual con el directorio del proyecto compartido. El código que podría escapar es cualquier cosa que se ejecute dentro de esa máquina, como un agente de codificación manipulado o cualquier software malicioso que el agente instale y ejecute. El escape se realiza con los derechos de la cuenta de host que ejecuta la máquina virtual.
La vulnerabilidad requiere código malicioso dentro del sandbox, y la protección del host contra lo que ejecuta un agente es precisamente el propósito del sandbox. El agente instala paquetes y ejecuta comandos con sudo dentro de la máquina virtual, y la documentación de aislamiento de Docker indica que el límite del hipervisor "es el control de aislamiento, no la separación de privilegios dentro de la VM".
El escape se produce a través del servidor host de virtio-fs, el lado del host para compartir archivos entre el Mac y la máquina virtual, que seguía enlaces simbólicos al reabrir un archivo eliminado desde una ruta almacenada, según Docker. Un invitado, es decir, cualquier cosa que se ejecute dentro de la máquina virtual, podría reemplazar un directorio padre con un enlace simbólico y luego leer o modificar archivos como el usuario del VMM (el monitor de máquina virtual), la cuenta de host bajo la cual se ejecuta dicho monitor, lo que "podría conducir a la ejecución de código en el host", según Docker. La documentación de Docker había advertido desde marzo que no se siguen los enlaces simbólicos que apunten fuera del espacio de trabajo (el término que usa Docker para el directorio de proyecto compartido).
Segunda vulnerabilidad corregida
La misma versión corrige una segunda falla, CVE-2026-79994, calificada como Alta por Docker con una puntuación CVSS de 8.7, en el relay que permite a un sandbox conectarse a sockets de dominio Unix dentro de su espacio de trabajo autorizado. El relay verificaba que la ruta del socket estuviera dentro del espacio de trabajo y luego se reconectaba usando el nombre de la ruta. Un invitado que reemplazara un directorio en esa ruta con un enlace simbólico entre la verificación y la conexión podría hacer que el host se conectara a cualquier socket AF_UNIX fuera del espacio de trabajo, lo que "expone datos o capacidades del lado del host proporcionadas por ese socket", según Docker.
Esta falla afecta a las versiones 0.37.0 a 0.41.9, pero no a la 0.42.0. Docker cataloga la primera falla como exclusiva de macOS, pero no especifica plataforma para la segunda, mientras que Docker Sandboxes se ejecuta en hosts macOS, Windows y Linux. La evaluación de CISA en su registro también indica que no hay explotación, y ninguna de las dos está en el catálogo de vulnerabilidades explotadas conocidas (KEV).
Versiones afectadas y recomendaciones
- Actualizar a la versión 0.42.0 o posterior. A fecha del 17 de septiembre, la versión más reciente es la 0.43.0, publicada el 15 de septiembre.
- Si no se puede actualizar aún, usar el modo clon y evitar añadir montajes de host de lectura y escritura. Es la recomendación de Docker para ambas fallas.
Por defecto, sbx run comparte el directorio actual en el sandbox con acceso de lectura y escritura. El modo clon solo funciona cuando el proyecto es un repositorio Git, y se establece al crear el sandbox, por lo que un sandbox existente debe eliminarse y crearse de nuevo con –clone. El modo clon protege el repositorio de cambios, no de lectura. El repositorio se monta como solo lectura en /run/sandbox/source, y los archivos no rastreados como .env permanecen legibles dentro del sandbox, según la documentación de Docker.
Publicación y créditos
Docker publicó los registros CVE y el aviso el 15 de septiembre, ocho días después de que se lanzara la versión 0.42.0. Las notas de la versión 0.42.0 en GitHub y en el sitio de documentación de Docker no mencionan ninguno de los CVE a fecha del 17 de septiembre. Entre las correcciones rutinarias, se incluye una para "un proceso en sandbox podría hacer que el daemon abriera un transporte D-Bus del host y ejecutara un comando arbitrario en el host". Docker no ha relacionado esa corrección con ninguno de los CVE.
El registro de CVE-2026-79994 inicialmente listaba la versión 0.41.0 como la primera versión corregida y enlazaba a una página de lanzamiento de la 0.41.0 que no existe. Docker corrigió ambos a la 0.42.0 aproximadamente una hora después de publicar el registro el 15 de septiembre. Docker atribuye el hallazgo de CVE-2026-77179 a Oren Yomtov de accomplish.ai y el de CVE-2026-79994 a Jurre van Bergen de ThreatNotify.
En abril, Cyera Research Labs describió cómo un agente de codificación con inyección de prompt dentro de un sandbox basado en Docker podría ser engañado para explotar una falla separada de Docker Engine contra su host.
Deja una respuesta