Las 9 principales vulnerabilidades de seguridad de contenedores Docker

¿Cuándo fue la última vez que revisó las imágenes de contenedores Docker que utiliza? Porque aquí está la cruda verdad: cada instrucción FROM, cada binario copiado y cada paquete instalado que forma su contenedor es un vector de ataque potencial. 

Esto significa que, si no inspecciona regularmente las capas de sus imágenes de contenedor y las dependencias en tiempo de compilación, es probable que esté heredando mucho más riesgo del que cree.

Las CVE (Vulnerabilidades y Exposiciones Comunes), las imágenes base inseguras, los secretos codificados y los privilegios excesivos son solo algunas de las formas en que los atacantes se cuelan. Y esto debería ser una preocupación para organizaciones como la suya.

De hecho, el informe de Red Hat de 2024 sobre el Estado de la Seguridad de Contenedores, que encuestó a 600 profesionales de DevOps, ingeniería y seguridad, reveló que casi la mitad de los equipos (42%) admite que la seguridad de los contenedores les quita el sueño. 

Desde vulnerabilidades en tiempo de ejecución de contenedores hasta CVEs que afectan a cargas de trabajo críticas de GPU, este artículo desglosa nueve de las vulnerabilidades de contenedores Docker más vitales y comúnmente pasadas por alto.

¿Qué son las vulnerabilidades de contenedores Docker?

Una vulnerabilidad de contenedor Docker es cualquier debilidad, mala configuración o fallo dentro de una imagen de contenedor, tiempo de ejecución o su infraestructura subyacente que los atacantes pueden explotar para comprometer la seguridad. Esto incluye tanto CVEs conocidos como problemas pasados por alto, como configuraciones predeterminadas inseguras, secretos expuestos o privilegios excesivos.

La velocidad y portabilidad que hacen que los contenedores Docker sean tan potentes para los desarrolladores también pueden convertirlos en una pesadilla para los equipos de seguridad. Por ejemplo, extraer una imagen con la etiqueta 'latest' o ejecutar contenedores como 'root' puede parecer inofensivo al principio. Pero en la práctica, estas son exactamente el tipo de aperturas que buscan los atacantes.

Una vulnerabilidad, en términos sencillos, es cualquier cosa en la configuración de su contenedor que facilita la tarea a alguien que intenta irrumpir.

Con esto en mente, desglosemos las nueve vulnerabilidades de contenedores Docker más comunes y peligrosas a las que debe prestar atención.

Las 9 principales vulnerabilidades en contenedores Docker

Las siguientes nueve vulnerabilidades son CVEs activos y configuraciones erróneas generalizadas observadas en entornos de producción. Cada una representa una ruta de amenaza práctica que puede conducir al compromiso del contenedor, al acceso al host o al movimiento lateral en su infraestructura.

Desglosémoslas.

1. Vulnerabilidades de escape de contenedores runC y Docker 

runC es un tiempo de ejecución de contenedores de 'bajo nivel' utilizado principalmente por tiempos de ejecución de contenedores de 'alto nivel' como Docker para generar y ejecutar contenedores. A lo largo de los años, hemos visto varias vulnerabilidades de escape de contenedores runC y Docker, que han resultado en ataques. 

Una importante, CVE-2019-5736, fue descubierta en febrero de 2019. Esta vulnerabilidad permitía a un atacante explotar una implementación de runC ejecutando una versión de Docker anterior a 18.09.2 sobrescribiendo el binario runC del host, comprometiendo así el acceso root del host. 

Aunque es una vulnerabilidad antigua (6 años a partir de 2025), muchos equipos todavía están expuestos a ella, especialmente en entornos con versiones de Docker/runC sin parchear o heredadas, tiempos de ejecución personalizados o bifurcados, etc. 

Un matiz crítico en la vulnerabilidad CVE-2019-5736 es que requiere que el proceso del contenedor se ejecute como usuario root. Supongamos que los contenedores se ejecutaran como contenedores sin root (por ejemplo, con USER 1000 en el Dockerfile o securityContext.runAsNonRoot: true en Kubernetes). En ese caso, los atacantes no pueden activar la ruta de sobrescritura porque carecen de los privilegios necesarios, razón por la cual es importante no ejecutar sus contenedores como usuario root.  

Desde 2019, han surgido más vulnerabilidades de escape de contenedores runC y Docker, algunas de baja severidad y otras críticas:

• CVE-2024-21626: Escape de contenedor a través de runC process.cwd y fds filtrados 
• CVE-2024-45310: Escape de contenedor para crear archivos o directorios vacíos
• CVE-2024-23651: Condición de carrera en la caché de montaje de Buildkit
• CVE-2024-23652: Eliminación arbitraria de contenedores en tiempo de compilación de Buildkit
• CVE-2024-23653: Verificación de privilegios de SecurityMode GRPC de Buildkit

Corregir estas vulnerabilidades de seguridad requiere actualizar los contenedores Docker afectados a una versión parcheada.

NOTA: Si no está seguro de qué versión de runC tiene en su entorno, ejecutar 'docker version' debería mostrar la versión como parte de la salida:

Severidad: Baja → Crítica

2. CVE-2025-9074: Acceso no autenticado a la API de Docker Engine desde contenedores

La API de Docker Engine proporciona una interfaz programática para interactuar con el demonio de Docker y gestionar objetos Docker. Está presente en todas las herramientas de Docker, incluido Docker Desktop. 

CVE-2025-9074 es una vulnerabilidad crítica similar a la falsificación de solicitudes del lado del servidor (SSRF) en Docker Desktop. Con esta vulnerabilidad, los contenedores pueden acceder a la API de Docker Engine a través de la subred de Docker configurada en 192.168.65.7:2375 por defecto, incluso con la “Aislación de Contenedores Mejorada” habilitada. Además, con o sin la opción "Exponer demonio en tcp://localhost:2375 sin TLS" habilitada.

La CVE-2025-9074 solo afecta a máquinas macOS y Windows. Aunque la mayoría de los sistemas de producción se ejecutan en Linux, como Docker, algunos utilizan Windows Server (especialmente si requieren el uso de contenedores Windows).

Los atacantes pueden explotar esta CVE con solo estas tres líneas de código Python a continuación:

The code above connects to the Docker daemon via TCP socket and runs a new Alpine container that creates a file exploit and mounts it to the host directory /Users/<username>. With that, when the container writes to the /mnt/exploit file, it writes to host /Users/<username>/exploit. 

Un atacante puede modificar el script para hacer cualquier cosa que el motor de Docker pueda hacer, incluyendo controlar otros contenedores, crear nuevos, gestionar imágenes, etc.

Si utilizas Docker Desktop en macOS o Windows, asegúrate de actualizar a la última versión, ya que esta vulnerabilidad ha sido corregida en la versión 4.44.3.

‍Gravedad: Crítica 

3. CVE-2022-0847: Dirty pipe (Escape del Kernel de Linux)

La CVE-2022-0847, una vulnerabilidad del kernel de Linux, se origina en un fallo en la lógica pipe_buffer.flags del código de pipes del kernel, que permite a un actor malicioso escribir en archivos de solo lectura, eludiendo protecciones como O_RDONLY e inmutable. Posteriormente, pueden escalar sus privilegios. 

Aunque no es una vulnerabilidad específica de contenedores, puede ser utilizada desde dentro de un contenedor Linux sin privilegios para sobrescribir binarios como /usr/bin/sudo en el host, inyectar puertas traseras y encadenar exploits.

La única solución conocida para esta vulnerabilidad es actualizar tus hosts Linux a versiones de Kernel parcheadas. 

Gravedad: Alta 

4. Imágenes Base Inseguras

Las imágenes base son el fundamento de cada contenedor que construyes, y si son vulnerables, también lo es tu aplicación. Desafortunadamente, al crear contenedores, muchos equipos todavía usan etiquetas de imagen como ubuntu:latest o node:alpine sin darse cuenta de que estas etiquetas son objetivos móviles. 

La última imagen que tu contenedor utiliza hoy podría ser diferente de la que utilice mañana. Esto puede introducir vulnerabilidades de seguridad inesperadas.  

Para mitigar esta vulnerabilidad, apunta a versiones específicas y de confianza (p. ej., FROM debian:bullseye-20230912) en lugar de usar etiquetas como latest. Y mientras utilizas versiones de confianza de una imagen en particular, recuerda escanear consistentemente utilizando herramientas como Aikido Security para detectar CVEs y vulnerabilidades AutoFix. 

También deberías escanear imágenes en tu registro de contenedores para corregir vulnerabilidades antes de que lleguen a tu entorno. Aikido también puede integrarse y escanear imágenes en tu registro de contenedores, ya sea Docker Hub o Harbor. 

‍

‍Gravedad: Baja → Crítica (Dependiendo de las imágenes de contenedor y el uso)

5. Acceso sin Restricciones al Socket de Docker

Montar el Socket de Docker, generalmente ubicado en (/var/run/docker.sock), en un contenedor es una de las configuraciones erróneas más peligrosas en entornos contenerizados. Hacer esto otorga al contenedor acceso completo a la API de Docker Engine, permitiéndole controlar todo el host. Lo cual no es inherentemente malo; sin embargo, un solo contenedor malicioso podría significar que un atacante ahora tiene el control de todo tu host. 

Los equipos a veces montan el Socket de Docker para permitir compilaciones "Docker-in-Docker" o que las herramientas de monitoreo gestionen contenedores, pero casi siempre es un atajo peligroso. 

Para mitigar esta vulnerabilidad, nunca debes montar el Socket de Docker en contenedores. Si requieres la funcionalidad Docker-in-Docker, debe aislarse en entornos de compilación estrictamente controlados utilizando Docker sin root, gVisor o Kata Containers. 

Si utilizas Kubernetes, deberías aplicar Estándares de Seguridad de Pods o políticas de admisión para bloquear el acceso de los contenedores a recursos a nivel de host como el Socket de Docker. 

Gravedad: Crítica

6. CVE-2025-23266: Vulnerabilidad de IA de NVIDIA (Fallo de Acceso a GPU)

La IA y el ML son todo de lo que hemos hablado en el último año. Esto se debe a que ha cambiado la forma en que trabajamos y vivimos en general. 

CVE-2025-23266 es una vulnerabilidad de escape de contenedor que afecta a NVIDIA Container Toolkit y GPU Operator, lo que nos permite construir y ejecutar contenedores acelerados por GPU.

NVIDIA Container Toolkit utiliza ganchos OCI (Open Container Initiative) (scripts o binarios personalizados) para configurar contenedores para el acceso a la GPU. Uno de estos ganchos, enable-cuda-compat, hereda variables de entorno del contenedor. Esto abre la puerta a que un atacante cree una imagen maliciosa que establezca LD_PRELOAD para hacer referencia a una biblioteca compartida maliciosa.  

Cuando el gancho privilegiado se ejecuta, la biblioteca se carga en el host, fuera del sandbox del contenedor, otorgando efectivamente al atacante acceso root en el nodo. 

En clústeres GPU multi-inquilino, esto crea un grave riesgo de fuga de datos entre inquilinos y compromiso del nodo.

NVIDIA ha lanzado versiones parcheadas de ambos componentes. La actualización a Toolkit v1.17.8 y GPU Operator 25.3.1 o la desactivación de un gancho opcional mitiga la vulnerabilidad.

Gravedad: Importante 

7. Secretos Expuestos

El Informe de Costo de una Brecha de Datos de IBM de 2025 revela que las brechas de datos causadas por credenciales comprometidas fueron las que más tardaron en identificarse y contenerse. Con un costo promedio de una brecha de datos de 4,4 millones de dólares, las organizaciones no pueden permitirse tener secretos expuestos. 

Sin embargo, siguen siendo uno de los errores más comunes que cometen los desarrolladores. Estos secretos incluyen credenciales sensibles como claves API, contraseñas, claves de cifrado, claves privadas y más, que podrían permitir a los atacantes acceder o robar datos confidenciales.

Los desarrolladores pueden filtrar secretos en contenedores Docker a través de:

• Dockerfiles (instrucciones ENV o ARG)
• archivos .env copiados en capas de imagen, etc. 

Lo alarmante es que, incluso después de eliminar un contenedor, si la imagen sigue presente (o se ha enviado a un registro), los secretos pueden seguir siendo accesibles.

Las probabilidades de que tu organización haya filtrado secretos son altas. Pero, ¿qué puedes hacer al respecto ahora mismo? 

Pues puedes y deberías:

• Encontrar cualquier secreto activo y luego 
• Evitar que cualquier nuevo llegue a producción. 

También existen algunas soluciones que ofrecen una función de detección de secretos en vivo que puede ayudarte a evaluar los riesgos potenciales de los secretos expuestos.

‍Gravedad: Alta

8. Vulnerabilidades de Privilegios de Contenedores

Como se mencionó anteriormente, no deberías ejecutar contenedores como usuarios root. Si bien esto no otorga automáticamente acceso al host, como has visto, aumenta significativamente el riesgo de escape cuando se combina con otras vulnerabilidades como CVE-2022-0492 o configuraciones erróneas en montajes de volumen y capacidades. 

Más allá de ejecutar contenedores como usuarios root, existen otras formas en que un contenedor puede ser vulnerable a través de privilegios. Esto es particularmente cierto cuando se utiliza un orquestador de contenedores como Kubernetes, que crea, modifica y elimina contenedores automáticamente. 

Con CVE-2023-2640 y CVE-2023-32629, un atacante puede usar un contenedor privilegiado no-root con montaje de volumen para escalar privilegios. 

En Kubernetes, usarías el Contexto de Seguridad para definir la configuración de privilegios y control de acceso para un contenedor.

En el Contexto de Seguridad anterior: 

• runAsNonRoot: true: Garantiza que el contenedor no se iniciará como UID 0
• runAsUser: 1000: Ejecuta explícitamente el contenedor como un usuario no root
• allowPrivilegeEscalation: false: Bloquea setuid u otras escaladas de privilegios
• capabilities.drop: [ALL]: Elimina todas las capacidades de Linux por defecto

Gestionar los privilegios y el acceso de los contenedores requiere comprender cómo se comporta su aplicación. Por ejemplo, si no realiza ninguna escritura en disco, entonces debería montar cualquier volumen asociado como de solo lectura, reduciendo aún más la superficie de ataque.

Lea nuestra guía sobre vulnerabilidades de escalada de privilegios en contenedores y cómo protegerse contra ellas.

Gravedad: Alta → Crítica

9. gh0stEdit: Vulnerabilidad de acceso basada en capas

Las imágenes Docker están diseñadas para garantizar que sus usuarios finales puedan evaluar y ver claramente el contenido de una imagen antes de ejecutarla. 

Pero en el caso de gh0stEdit, esa visibilidad no importa. 

Aunque no es una CVE formal, gh0stEdit (nombre dado por sus investigadores) describe una vulnerabilidad novedosa donde un atacante puede manipular imágenes Docker (incluso firmadas con Docker Content Trust) sin romper la firma de la imagen o ser detectado por escaneos estáticos/dinámicos. 

Figura 1: Bypass de la integridad de la imagen Docker: Capas modificadas, Manifiesto inalterado. Fuente (Hackernoon)‍

Esta manipulación es posible porque Docker se centra en el manifiesto (la "receta" que enumera las capas de la imagen y sus digests), y no en cada archivo individual dentro de cada capa. 

Si un atacante inyecta un script malicioso en una capa, el contenedor se ejecuta, eludiendo el Dockerfile, el proceso de compilación y las comprobaciones del registro. Puede propagarse silenciosamente por todo su sistema. 

La corrección y defensa contra gh0stEdit implica varios pasos, incluyendo:

• Reconstruir siempre las imágenes de contenedor desde fuentes de confianza
• Firma y verificación de imágenes de contenedor con herramientas como cosign
• El escaneo de vulnerabilidades y contenido con herramientas como Aikido complementa los escáneres de código abierto con reglas personalizadas, cubriendo brechas y revelando fallos de seguridad. 
• Utilizar un controlador de admisión para evitar que imágenes no firmadas o no escaneadas se ejecuten dentro de su clúster.

Gravedad: Baja → Crítica (Dependiendo de las imágenes de contenedor y la superficie de ataque)

Construyendo una Postura de Seguridad Docker Resiliente

Como exploramos en este artículo, vulnerabilidades como las fugas de contenedores runC, las imágenes base no escaneadas, los secretos expuestos y los privilegios excesivos pueden socavar silenciosamente todo su entorno. 

Implementar una postura de seguridad Docker resiliente significa ir más allá de los escaneos superficiales hacia defensas contextuales, conscientes del tiempo de ejecución y basadas en políticas que encuentran y corrigen vulnerabilidades automáticamente. 

En Aikido, nos encantan los proyectos de código abierto consolidados como Trivy, Syft y Grype. Pero también sabemos por experiencia que usarlos de forma aislada no ofrece una experiencia de desarrollador particularmente buena. 

Aikido mejora estos proyectos con reglas personalizadas para cubrir brechas y revelar fallos de seguridad que de otro modo no podrías encontrar. A diferencia de encadenar varias herramientas de código abierto, Aikido te libera de tener que construir un script de escaneo o crear un trabajo personalizado en tu CI/CD.

Siempre hay más que aprender sobre la seguridad de Docker. Para responder a más preguntas sobre cómo mantener Docker seguro, consulta nuestra lista de verificación de seguridad de Docker sin rodeos para el desarrollador consciente de las vulnerabilidades. 

Sigue leyendo:
Las 7 principales seguridad en la nube    
Las 10 principales vulnerabilidades de seguridad de las aplicaciones web que todo equipo debe conocer    
Las 9 principales seguridad Kubernetes y configuraciones erróneas seguridad Kubernetes    
Las principales vulnerabilidades de seguridad del código que se encuentran en las aplicaciones modernas    
Las 10 principales vulnerabilidades de seguridad de Python que los desarrolladores deben evitar    
Las 10 principales vulnerabilidades de seguridad de JavaScript en aplicaciones web modernas    
Las 9 principales seguridad de la cadena de suministro de software explicadas