Docker en riesgo: CVE-2026-34040 permite bypass de AuthZ y exposición de secretos con una única petición HTTP inflada

Hace poco se hizo pública una vulnerabilidad de alta gravedad en Docker Engine que, en determinadas condiciones, permite eludir los plugins de autorización (AuthZ) y conseguir que el demonio de Docker realice acciones que deberían haber sido bloqueadas. Identificada como CVE-2026-34040 y valorada con una puntuación CVSS de 8.8, la falla nace de una corrección incompleta aplicada tras una incidencia anterior en el mismo componente, vinculada a CVE-2024-41110. Para quien administre entornos con Docker, esto no es solo un fallo técnico: es una puerta de entrada que puede derivar en la exposición de credenciales y en la toma de control de recursos en la nube y clústeres de Kubernetes.

En términos sencillos, el problema ocurre cuando una petición HTTP especialmente manipulada —con un cuerpo demasiado grande— hace que el demonio de Docker reenvíe la solicitud a un plugin de autorización sin incluir ese cuerpo. Si el plugin basa su decisión de permitir o denegar la operación en el contenido de la petición (por ejemplo, en la configuración de creación de un contenedor), y recibe una petición vacía, puede conceder permisos que normalmente habría denegado. Tras aceptar la operación, el demonio procesa la versión completa y debidamente rellena del cuerpo y acaba creando, por ejemplo, un contenedor privilegiado con acceso al sistema de ficheros del anfitrión.

La raíz de la vulnerabilidad está asociada a cómo se trató el parche anterior para la vulnerabilidad de 2024: la corrección no contempló adecuadamente cuerpos de petición por encima de cierto umbral (alrededor de 1 MB), lo que permitió un escenario en el que una sola petición HTTP «inflada» puede terminar creando un contenedor con privilegios de host. Investigadores que han participado en el hallazgo y la divulgación del problema incluyen a varias personas e instituciones que informaron de forma independiente, y la corrección se publicó en la versión Docker Engine 29.3.1.

Más preocupante aún es la posibilidad de que agentes de codificación basados en inteligencia artificial, que operan dentro de sandboxes Docker (por ejemplo, asistentes que automatizan tareas de desarrollo), puedan ser manipulados para ejecutar una cadena de acciones que dé lugar a este bypass. Un repositorio de código con instrucciones maliciosas ocultas o incluso un agente que, de forma autónoma, intente resolver un fallo (por ejemplo, acceder a un kubeconfig para depurar un problema) podría construir la petición acolchada que desencadena la vulnerabilidad sin necesidad de código de explotación sofisticado. En otras palabras, cualquier entidad con acceso al API de Docker y conocimiento básico de HTTP podría reproducir el bypass: no se necesitan herramientas avanzadas ni privilegios adicionales más allá del acceso que ya se emplea en un flujo legítimo.

El impacto potencial es grave. Con un contenedor privilegiado y el sistema de ficheros del host montado, un atacante puede extraer claves SSH, credenciales de acceso a proveedores de nube, archivos de configuración de Kubernetes y otros secretos que permitan escalar el compromiso hasta cuentas en la nube, clústeres enteros o servidores de producción. Por eso, la recomendación más urgente es actualizar a la versión parcheada de Docker Engine lo antes posible y revisar la exposición del API de Docker en tus sistemas.

Como medidas inmediatas mientras se despliega la actualización, se aconseja evitar depender de plugins de autorización cuya lógica se base en inspeccionar el cuerpo de las peticiones para tomar decisiones críticas, y aplicar el principio de menor privilegio en el acceso al API de Docker: restringirlo únicamente a actores confiables y minimizar qué credenciales/roles pueden usarlo. Además, ejecutar Docker en modo rootless reduce drásticamente la superficie de ataque, ya que el «root» dentro de un contenedor deja de corresponderse con el usuario root del sistema anfitrión; para entornos donde no es viable un cambio completo, la remapificación de usuarios con opciones como --userns-remap ofrece una mitigación parcial que disminuye el impacto de un contenedor comprometido.

Si quieres consultar fuentes oficiales y ampliar detalles técnicos, conviene revisar la documentación y avisos de seguridad de Docker en su sitio oficial, la cobertura de medios especializados que siguieron la divulgación y el análisis técnico publicado por equipos de investigación en ciberseguridad. Podemos empezar por la página de seguridad de Docker en https://docs.docker.com/engine/security/, donde se anuncian boletines y notas de versión; la documentación sobre ejecución sin privilegios en https://docs.docker.com/engine/security/rootless/ y sobre remapeo de usuarios; el portal de vulnerabilidades y bases de datos públicas como NVD (National Vulnerability Database) o MITRE CVE para seguir los identificadores oficiales; y los análisis de equipos independientes que han investigado la técnica de explotación y sus implicaciones.

Esta clase de fallos subraya dos lecciones importantes para equipos de ingeniería y seguridad: primero, las correcciones rápidas e incompletas en componentes críticos pueden dejar huellas explotables que aparecen más tarde en forma de bypasses; segundo, el auge de herramientas automatizadas y agentes AI introduce vectores nuevos que combinan errores clásicos de seguridad con comportamientos autónomos imprevisibles. Mantenerse actualizado, reducir la superficie de exposición y repensar la confianza en mecanismos que inspeccionan contenidos transmitidos por la red son medidas clave para reducir el riesgo hasta que todas las máquinas del parque estén protegidas.