Docker Desktop, la herramienta más extendida entre desarrolladores y administradores de sistemas para desplegar entornos de contenedores en estaciones de trabajo, ha quedado en el centro de la polémica tras descubrirse una vulnerabilidad crítica que pone en riesgo a millones de equipos.
El fallo, identificado como CVE-2025-9074 y con una puntuación de 9,3 en la escala CVSS, afecta a Docker Desktop en Windows y macOS. No impacta a entornos Linux, ya que el modelo de ejecución es diferente.
El problema radica en un SSRF (Server-Side Request Forgery) que expone la API interna de Docker Engine (http://192.168.65.7:2375/) a cualquier contenedor en ejecución sin autenticación. El resultado: un atacante que logre desplegar un contenedor malicioso podría ejecutar comandos en el host, lanzar nuevos contenedores con privilegios elevados y acceder a todo el sistema de archivos.
Impacto real para administradores de sistemas
Los administradores de sistemas deben entender que esta vulnerabilidad rompe uno de los pilares de la seguridad en entornos Docker: el aislamiento de los contenedores respecto al host.
- En Windows, donde Docker Desktop se apoya en WSL2, el atacante puede montar la unidad C: completa en un contenedor y con ello:
- Leer cualquier archivo del sistema, incluidas claves privadas y credenciales.
- Sobrescribir DLLs del sistema, logrando escalada a administrador del host.
- Persistir en el sistema con puertas traseras.
- En macOS, la seguridad intrínseca del sistema limita los daños, ya que el usuario debe aprobar explícitamente accesos a directorios fuera del sandbox. No obstante, el atacante mantiene control total sobre Docker Desktop y los contenedores, lo que le permite manipular configuraciones, inyectar backdoors o alterar imágenes.
En ambos casos, el aislamiento reforzado de contenedores (ECI, Enhanced Container Isolation) no sirve como mitigación, ya que la explotación se produce a nivel del plano de control de Docker.
Cómo se explota el fallo
El investigador Felix Boulet, responsable del hallazgo, demostró que bastan dos llamadas HTTP POST desde dentro de un contenedor para comprometer el host:
- Crear un nuevo contenedor solicitando el montaje del disco del host (
C:en Windows) en un directorio interno (/host_root). - Arrancar ese contenedor y ejecutar cualquier comando sobre los archivos montados.
Este procedimiento ni siquiera requiere permisos de ejecución de código adicionales dentro del contenedor. Un simple PoC en Python de tres líneas fue suficiente para demostrar la gravedad del fallo.
Recomendaciones inmediatas para sysadmins
Docker ha publicado un parche en la versión 4.44.3 de Docker Desktop que corrige la exposición de la API interna. La medida más importante es actualizar cuanto antes.
Pero más allá del parche, los administradores deben reforzar sus prácticas de seguridad:
- Verificar la versión de Docker Desktop:
docker --versiony asegurarse de estar en>= 4.44.3. - Restringir el uso de contenedores no confiables en entornos Windows/macOS. Cualquier imagen externa debe validarse antes de ejecutarse.
- Aplicar políticas de red internas y segmentación, incluso en entornos de desarrollo, para evitar que contenedores tengan visibilidad innecesaria sobre interfaces internas.
- Auditar los permisos de los usuarios de Docker: el principio de least privilege es esencial. Un desarrollador no debería poder ejecutar contenedores con privilegios elevados en un portátil corporativo sin justificación.
- Reforzar controles de endpoint: herramientas de EDR/XDR pueden detectar comportamientos anómalos, como procesos que acceden masivamente a
C:\Windows\System32desde un binario de Docker.
Lecciones para la administración de entornos Docker
Este incidente pone de relieve varias lecciones clave que todo sysadmin debería incorporar:
- No confiar en interfaces “internas”. Una API expuesta en una red privada debe considerarse tan vulnerable como una expuesta públicamente si no está protegida por autenticación.
- Zero trust incluso dentro del host: el hecho de que un contenedor se ejecute en una máquina de desarrollo no lo convierte en seguro.
- Escaneos internos periódicos: usar herramientas como
nmap,netstatosspara auditar puertos internos y servicios expuestos puede revelar configuraciones erróneas antes que los atacantes. - Formación en DevSecOps: integrar la seguridad en el ciclo de desarrollo es clave. Esta vulnerabilidad demuestra que errores básicos en la arquitectura pueden escalar a problemas críticos de seguridad.
Conclusión
El CVE-2025-9074 es un recordatorio contundente de que la seguridad en contenedores no puede darse por sentada. La simplicidad del exploit, unido a su capacidad para comprometer completamente un host Windows, lo convierte en uno de los fallos más graves de los últimos años en Docker Desktop.
Para los administradores de sistemas, el mensaje es claro: parchear inmediatamente, reforzar las prácticas de hardening en entornos de desarrollo y producción, y asumir que incluso herramientas maduras como Docker pueden tener grietas inesperadas.
La virtualización ligera ha transformado la manera de desplegar servicios, pero la seguridad debe evolucionar al mismo ritmo. Un contenedor malicioso no debería ser capaz de tumbar la barrera que separa al host de sus cargas, y este fallo demuestra por qué la vigilancia constante sigue siendo indispensable.
Preguntas frecuentes (FAQ)
1. ¿Qué versiones de Docker Desktop están afectadas?
Todas las versiones anteriores a la 4.44.3 en Windows y macOS. Docker en Linux no está afectado.
2. ¿El aislamiento reforzado de contenedores (ECI) protege frente a esta vulnerabilidad?
No. ECI no mitiga el problema porque el fallo se produce en la API de control de Docker, no en la ejecución interna de los contenedores.
3. ¿Qué medidas deben adoptar los administradores además de actualizar?
- Segmentar la red interna de contenedores.
- Restringir el uso de imágenes no verificadas.
- Auditar permisos y roles de Docker.
- Monitorizar actividad anómala en el host.
4. ¿Qué riesgos concretos hay en Windows y macOS?
- Windows: acceso total al sistema de archivos, robo de credenciales y escalada a administrador.
- macOS: limitaciones mayores, pero aún riesgo de manipulación de configuraciones, backdoors y alteración de imágenes.
vía: Noticias seguridad y CVE-2025-9074
