Se ha revelado una vulnerabilidad de seguridad de alta gravedad en Docker Engine que podría permitir a un atacante eludir los complementos de autorización (AuthZ) en circunstancias específicas.
La vulnerabilidad, rastreada como CVE-2026-34040 (Puntuación CVSS: 8,8), surge de una solución incompleta para CVE-2024-41110, una vulnerabilidad de gravedad máxima en el mismo componente que salió a la luz en julio de 2024.
«Utilizando una solicitud API especialmente diseñada, un atacante podría hacer que el demonio Docker reenvíe la solicitud a un complemento de autorización sin el cuerpo», mantenedores de Docker Engine. dicho en un aviso publicado a finales del mes pasado. «El complemento de autorización puede permitir una solicitud que de otro modo habría rechazado si se le hubiera enviado el cuerpo».
«Cualquiera que dependa de complementos de autorización que introspeccionen el cuerpo de la solicitud para tomar decisiones de control de acceso se verá potencialmente afectado».
A múltiples vulnerabilidades de seguridad, incluidas Asim Viladi Oglu Manizada, Cody, Oleh Konko y Vladimir Tokarev, se les atribuye el mérito de descubrir e informar el error de forma independiente. El problema se solucionó en la versión 29.3.1 de Docker Engine.
Según un informe publicado por el investigador Tokarev de Cyera Research Labs, la vulnerabilidad se debe al hecho de que la solución para CVE-2024-41110 no manejó adecuadamente los cuerpos de solicitud HTTP de gran tamaño, abriendo así la puerta a un escenario en el que se puede utilizar una única solicitud HTTP rellenada para crear un contenedor privilegiado con acceso al sistema de archivos host.
En un escenario de ataque hipotético, un atacante que tiene el acceso a la API de Docker restringido por un complemento AuthZ puede socavar el mecanismo al rellenar una solicitud de creación de contenedor a más de 1 MB, lo que provoca que se elimine antes de llegar al complemento.
«El complemento permite la solicitud porque no ve nada que bloquear», Tokarev dicho en un informe compartido con The Hacker News. «El demonio Docker procesa la solicitud completa y crea un contenedor privilegiado con acceso raíz al host: sus credenciales de AWS, claves SSH, configuraciones de Kubernetes y todo lo demás en la máquina. Esto funciona con todos los complementos de AuthZ en el ecosistema».
Es más, un agente codificador de inteligencia artificial (IA) como OpenClaw ejecutándose dentro de una zona de pruebas basada en Docker se puede engañar para que ejecute una inyección rápida oculta dentro de un repositorio GitHub específicamente diseñado como parte de un flujo de trabajo normal del desarrollador, lo que resulta en la ejecución de código malicioso que explota CVE-2026-34040 para eludir la autorización utilizando el enfoque anterior y crear un contenedor privilegiado y montar el sistema de archivos host.
Con este nivel de acceso, el atacante puede extraer credenciales para servicios en la nube y abusar de ellas para tomar el control de cuentas en la nube, clústeres de Kubernetes e incluso SSH en servidores de producción.
No termina ahí. Cyera también advirtió que los agentes de IA pueden descubrir el bypass por su cuenta y activarlo mediante la construcción de una solicitud HTTP rellenada al encontrar errores al intentar acceder a archivos como kubeconfig como parte de una tarea de depuración legítima emitida por un desarrollador (por ejemplo, depurar el problema de falta de memoria del K8). Este enfoque elimina la necesidad de instalar un repositorio envenenado que contenga instrucciones maliciosas.
«El complemento AuthZ negó la solicitud de montaje», explicó Cyera. «El agente tiene acceso a la API de Docker y sabe cómo funciona HTTP. CVE-2026-34040 no requiere ningún código de explotación, privilegios o herramientas especiales. Es una única solicitud HTTP con relleno adicional. Cualquier agente que pueda leer la documentación de la API de Docker puede construirla».
Como solución temporal, se recomienda evitar el uso de complementos de AuthZ que dependen de la inspección del cuerpo de solicitud para tomar decisiones de seguridad, limitar el acceso a la API de Docker a partes confiables siguiendo el principio de privilegio mínimo o ejecutar Docker en modo desarraigado.
«En el modo sin raíz, incluso la 'raíz' de un contenedor privilegiado se asigna a un UID de host sin privilegios», dijo Tokarev. «El radio de explosión cae de 'compromiso total del host' a 'usuario comprometido sin privilegios'. Para entornos que no pueden desraizarse por completo, –userns-remap proporciona un mapeo de UID similar».
