Docker ha lanzado correcciones para abordar una falla de seguridad crítica que afecta a la aplicación Docker Desktop para Windows y MacOS que podría permitir que un atacante salga de los límites de un contenedor.
La vulnerabilidad, rastreada como CVE-2025-9074lleva una puntuación CVSS de 9.3 de 10.0. Se ha abordado en la versión 4.44.3.
«Un contenedor malicioso que se ejecuta en Docker Desktop podría acceder al motor Docker y lanzar contenedores adicionales sin requerir que el Socket Docker se monte», dijo Docker en un aviso publicado la semana pasada.
«Esto podría permitir el acceso no autorizado a los archivos de usuario en el sistema de host. El aislamiento de contenedores mejorado (ECI) no mitiga esta vulnerabilidad».
Según el investigador de seguridad Felix Boulet, la vulnerabilidad tiene que ver con cómo es posible que un contenedor se conecte a la API del motor Docker en 192.168.65 (.) 7: 2375 sin requerir ninguna autenticación, abriendo así la puerta a un escenario en el que un contenedor privilegiado podría obtener acceso completo al huésped subyacente al montar el c: disco en él.
En una exploit de prueba de concepto (POC), se ha encontrado que una solicitud web de cualquier contenedor desencadena el defecto y da como resultado un compromiso completo del host-
- Publique una carga útil JSON a «/Contengeters/Create», vinculando el host C: Drive a una carpeta en el contenedor (/mnt/host/c:/host_root) en el contenedor, y utilizando un comando de inicio para escribir o leer cualquier cosa en/host_root en el inicio del contenedor.
- Publicar en «/contenedores/{id}/inicio» para iniciar el contenedor e iniciar la ejecución
«En esencia, esta vulnerabilidad fue una simple supervisión, la API HTTP interna de Docker fue accesible desde cualquier contenedor sin autenticación o control de acceso», dijo Boulet.
El investigador de Pvotal Technologies Philippe Dugre («Zer0x64»), quien examinó más al fallas, dijo que un atacante puede explotar la falla en la versión de Windows del escritorio de Docker para montar como administrador todo el sistema de archivos, leer cualquier archivo confidencial y sobrevisar un sistema de un sistema para aumentar el atacante al administrador del sistema anfitrión.
«Sin embargo, en MacOS, la aplicación Docker Desktop todavía tiene una capa de aislamiento y la intento de montar un directorio de usuario solicita permiso al usuario», dijo Dugre. «Por defecto, la aplicación Docker no tiene acceso al resto del sistema de archivos y no se ejecuta con privilegios administrativos, por lo que el host es mucho más seguro que en el caso de la ventana».
«Sin embargo, el atacante todavía tiene el control total de la aplicación/contenedores Docker e incluso puede verlo al montar y modificar la configuración de la aplicación, que no necesita ninguna aprobación del usuario».
La vulnerabilidad no afecta la versión de Linux ya que Linux usa una tubería con nombre en el sistema de archivos del host, en lugar de confiar en un socket TCP TCP para la API del motor Docker.
La forma más fácil de aprovechar la vulnerabilidad es a través de un contenedor malicioso controlado por el actor de amenaza. Dicho esto, una falla de falsificación de solicitud del lado del servidor (SSRF) puede usarse como un vector de ataque alternativo.
«Esta vulnerabilidad permite a un atacante a las solicitudes proxy a través de la aplicación vulnerable y alcanzar el socket de Docker, cuyo impacto varía especialmente dependiendo de la disponibilidad de los métodos de solicitudes HTTP (la mayoría de SSRF solo permite solicitudes GET, pero algún caso de nicho permite el uso de Post, Patch, Delete Methods)», dijo Dugre.