La comunidad de ciberseguridad ha encendido las alarmas tras conocerse una vulnerabilidad crítica en Docker Desktop para Windows y macOS, identificada como CVE-2025-9074, que permite a un atacante comprometer el sistema host mediante un contenedor malicioso. El fallo, de tipo SSRF (Server-Side Request Forgery), recibió una calificación de 9,3 sobre 10 en la escala CVSS, situándose en el rango de máxima severidad.
La vulnerabilidad fue descubierta por el investigador de seguridad Felix Boulet, quien halló que cualquier contenedor en ejecución podía acceder a la API de Docker Engine sin autenticación a través de la dirección interna http://192.168.65.7:2375/. A partir de ahí, bastaban un par de peticiones HTTP para crear y arrancar nuevos contenedores con acceso al sistema de archivos del host.
¿Qué estaba en riesgo?
Docker Desktop es la puerta de entrada al mundo de la virtualización ligera para millones de desarrolladores. Sin embargo, en este caso, la capa de aislamiento resultó ineficaz frente a un ataque extremadamente sencillo:
- En Windows, el atacante podía montar la unidad C: completa del host y acceder a cualquier archivo, incluidos documentos personales, credenciales y configuraciones sensibles. Peor aún, podía sobrescribir DLLs del sistema y escalar privilegios hasta convertirse en administrador.
- En macOS, la situación era menos grave, ya que el sistema operativo impone permisos adicionales. Aunque el exploit no permitía directamente el acceso a todo el sistema, sí podía modificar la configuración de Docker Desktop o instalar puertas traseras dentro del entorno de contenedores.
Lo más alarmante es que el exploit de prueba de concepto (PoC) constaba de apenas tres líneas de código en Python. Una demostración contundente de que la simplicidad de un fallo no está reñida con su peligrosidad.
Por qué ECI no fue suficiente
Docker había promocionado el Enhanced Container Isolation (ECI) como una medida de seguridad clave para proteger a los usuarios frente a contenedores maliciosos. Sin embargo, este mecanismo no mitigaba el fallo.
El motivo: el problema no estaba en la ejecución interna del contenedor, sino en la exposición de la API de control sin autenticación. En la práctica, cualquier contenedor podía comportarse como un administrador oculto, lanzando órdenes al motor principal sin restricción.
Como señaló Philippe Dugre, ingeniero de DevSecOps en Pvotal Technologies, “el control plane estaba expuesto a las cargas de trabajo que debía aislar, y eso rompe por completo el modelo de seguridad”.
Cómo se descubrió
Paradójicamente, Boulet encontró la vulnerabilidad casi por accidente. Según relató en su propio blog, llevaba tiempo escaneando entornos de contenedores en busca de inconsistencias, hasta que detectó el puerto abierto de la API en la red privada documentada por Docker.
El PoC es tan directo como preocupante:
- Enviar una petición
POSTpara crear un contenedor, montando el disco del host en una carpeta interna del contenedor. - Enviar otra petición
POSTpara iniciar ese contenedor y ejecutar comandos sobre el sistema host.
Ni ejecución previa de código dentro del contenedor, ni permisos adicionales: solo dos solicitudes HTTP bastaban para “romper” la promesa de aislamiento de Docker Desktop.
Respuesta de Docker
La vulnerabilidad fue reportada de manera responsable y la empresa reaccionó con rapidez. La versión 4.44.3 de Docker Desktop, publicada la semana pasada, incluye el parche que bloquea el acceso no autenticado a la API interna.
Docker recomendó a todos los usuarios de Windows y macOS actualizar de inmediato. La versión para Linux no se ve afectada, ya que el modelo de ejecución difiere y no expone la misma interfaz.
Aunque no existe un programa de recompensas oficial para este tipo de hallazgos, Boulet confirmó que recibirá un paquete de merchandising como gesto de agradecimiento.
Lecciones aprendidas
El caso de CVE-2025-9074 deja varias enseñanzas clave para el sector:
- Nunca dar por seguro lo “interno”: que una API esté en una red privada no significa que esté protegida.
- Autenticación obligatoria en todos los endpoints, incluso los destinados a tareas internas.
- Pruebas de aislamiento constantes: escanear los entornos como si uno fuera el atacante puede descubrir errores críticos antes que ellos.
- Colaboración abierta: los programas de bug bounty, públicos o privados, siguen siendo una herramienta esencial para detectar fallos de este calibre.
Conclusión
La vulnerabilidad en Docker Desktop recuerda que incluso las plataformas más usadas pueden contener errores básicos con efectos devastadores. Un bug que parecía trivial —un puerto accesible sin autenticación— se tradujo en una brecha capaz de dar control total de un host Windows o comprometer parcialmente macOS.
En un contexto donde los contenedores son el motor de la infraestructura digital moderna, el incidente reafirma la necesidad de mantener una vigilancia constante y un enfoque de “zero trust” incluso dentro del propio entorno local.
Docker ya ha corregido el fallo, pero el CVE-2025-9074 quedará como un recordatorio incómodo de que la seguridad empieza por cuestionar siempre las suposiciones.
Preguntas frecuentes (FAQ)
1. ¿Qué versiones de Docker Desktop están afectadas?
Todas las versiones anteriores a Docker Desktop 4.44.3 en Windows y macOS. La versión para Linux no está afectada.
2. ¿Qué riesgos implica la vulnerabilidad?
En Windows, el atacante puede leer y modificar todo el sistema de archivos e incluso escalar a administrador. En macOS, los riesgos son menores, pero aún permiten manipular la configuración de Docker y generar puertas traseras.
3. ¿Cómo puedo protegerme?
La recomendación principal es actualizar a Docker Desktop v4.44.3 o posterior. También se aconseja reforzar políticas de red, cerrar puertos innecesarios y aplicar un enfoque de zero trust dentro de los entornos de desarrollo.
4. ¿Qué medidas adicionales deberían adoptar los equipos de seguridad?
- Ejecutar auditorías periódicas de red en entornos de contenedores.
- Configurar controles de acceso estrictos a APIs internas.
- Fomentar la formación en DevSecOps para detectar malas configuraciones antes de que lleguen a producción.
vía: Docker, CVE-2025-9074 y blog.qwertysecurity
