CVE-2026-34040: bypass de 1 MB en Docker AuthZ

Los plugins de autorización (AuthZ) son, para mucha gente, la última línea de defensa del daemon de Docker: el guardia que decide qué peticiones a la API se permiten y cuáles no. CVE-2026-34040 demuestra que ese guardia se puede engordar hasta dejarlo ciego. Con un solo pedido HTTP inflado a más de 1 MB, el plugin ve un cuerpo vacío, aprueba la operación, y el daemon —que sí lee el pedido completo— termina levantando un contenedor privilegiado con acceso root al sistema anfitrión. Sin exploit, sin herramientas raras: una petición con relleno.

CVE-2026-34040 es una vulnerabilidad de alta severidad (CVSS 8.8) en Docker Engine, descubierta por Cyera Research y parcheada en la versión 29.3.1 (marzo de 2026). Permite saltear los plugins de autorización (AuthZ): cuando el cuerpo de una petición a la API supera 1 MB, Docker lo descarta antes de que el plugin lo evalúe, pero el daemon igual lo procesa. El resultado es un contenedor privilegiado con la raíz del host montada y control total del servidor.

¿Por qué una falla de Docker de marzo es tema justo ahora?

CVE-2026-34040: el bypass de 1 MB en el AuthZ de Docker

La divulgación es de fines de marzo de 2026, pero el caso ganó tracción en el ecosistema por tres motivos que lo mantienen vigente, y que son exactamente lo que lo convierte en tendencia y no en una nota de archivo:

El vector de los agentes de IA lo puso en primer plano. Cada vez más equipos corren agentes de coding autónomos dentro de sandboxes basados en Docker. Un agente al que se le cuela una prompt injection escondida en un repositorio de GitHub puede construir la petición maliciosa por su cuenta: le alcanza con leer la documentación de la API de Docker. No hace falta un atacante “manual”.
Es una regresión de un bug conocido. Al ser el mismo componente que CVE-2024-41110, el trabajo de ingeniería inversa para armar un exploit funcional es corto. Las fuentes de seguridad advierten que ese código probablemente ya está circulando entre actores maliciosos.
El parque instalado tarda en actualizar. Docker Engine no se actualiza solo en la mayoría de los servidores. Miles de hosts con un plugin AuthZ activo siguen corriendo versiones previas a la 29.3.1 semanas después del parche.

¿Cómo funciona el bypass de 1 MB en el AuthZ de Docker?

La raíz del problema es una desincronización entre dos partes del daemon que deberían ver lo mismo y no lo ven. El middleware que le pasa la petición al plugin y el motor que la ejecuta tratan un cuerpo grande de forma distinta:

El atacante infla el cuerpo JSON. A una petición normal de creación de contenedor le agrega un campo de relleno (padding) hasta que el cuerpo total cruza el umbral de 1 MB. El parser JSON de Docker ignora ese campo extra sin chistar.
El middleware descarta el cuerpo. Como supera 1 MB, Docker lo trunca antes de reenviarlo al plugin AuthZ. El plugin recibe un cuerpo vacío.
El plugin aprueba a ciegas. Sin nada que inspeccionar, la política del plugin no encuentra motivo para bloquear y deja pasar la operación.
El daemon ejecuta el pedido completo. A diferencia del plugin, el motor sí lee el cuerpo entero —incluida la parte que pide privilegios— y crea el contenedor tal cual se solicitó.

Con esa mecánica, la petición puede pedir un contenedor con Privileged: true y el filesystem del host montado. Una vez adentro, el atacante tiene la raíz del servidor: claves SSH, configuraciones de Kubernetes, secretos de la aplicación y credenciales de tu proveedor cloud quedan a mano.

¿Qué relación tiene con CVE-2024-41110?

CVE-2026-34040 es, textualmente, una regresión de CVE-2024-41110, aquella falla de severidad máxima (CVSS 10.0) parcheada en julio de 2024. Aquel bug permitía saltear el AuthZ con peticiones de Content-Length: 0 —es decir, por el extremo de cero bytes—. El arreglo de 2024 tapó ese extremo, pero dejó el otro abierto: los cuerpos que superan 1 MB. La lección de fondo es incómoda: se validó el borde de abajo y se olvidó el de arriba, y dos años después el mismo camino volvió a quedar transitable.

¿A quién afecta y a quién no?

Esto es clave para no entrar en pánico ni relajarse de más. La vulnerabilidad tiene un alcance acotado, pero severo donde pega:

Te afecta si usás un plugin AuthZ que decide según el cuerpo de la petición. Es el escenario típico en entornos multi-tenant o corporativos que ponen un plugin de autorización delante del daemon para aplicar políticas de acceso finas.
No te afecta si no usás plugins AuthZ. El aviso oficial es explícito: sin un plugin de autorización en juego, no sos vulnerable a este CVE en particular. Docker por defecto no trae uno.
Ojo con los sandboxes de agentes de IA. Si corrés agentes autónomos en contenedores y confiás en un plugin AuthZ para contenerlos, sos justo el blanco del vector que hizo ruido con este caso.

Aun si hoy no usás un plugin AuthZ, actualizar sigue siendo la jugada correcta: no querés depender de esa condición el día que sumes uno.

¿Qué implica para un proyecto en producción?

El impacto no es “se cae un contenedor”. Es escape de contenedor a root del host, que en la práctica equivale a comprometer toda la máquina y, desde ahí, potencialmente el resto de tu infraestructura. Si ese host tiene credenciales de despliegue, acceso a tu clúster de Kubernetes o tokens de CI/CD, el radio de explosión se extiende mucho más allá del servidor tocado. Y como el bypass no deja rastro evidente en el plugin (que “aprobó” la operación con total normalidad), la detección tardía es parte del problema.

¿Qué podés hacer HOY?

La respuesta corta es una sola: actualizar. La respuesta completa incluye defensa en profundidad por si no podés parchear ya mismo.

Actualizá a Docker Engine 29.3.1 o superior. Es el arreglo que aplica un comportamiento fail-closed: ante un cuerpo que no puede evaluarse, ahora se bloquea en vez de dejar pasar. Verificá tu versión antes y después con docker version.
Si usás Docker Desktop, subí a la build parcheada. El arreglo también se distribuyó por ese canal; revisá que estés en la versión que incorpora el fix del Engine 29.3.x.
Limitá el acceso a la API de Docker. Principio de mínimo privilegio: solo actores de confianza deberían poder hablarle al daemon. Nunca expongas el socket ni el puerto de la API a redes no confiables.
Evaluá correr Docker en modo rootless. Ahí, incluso el “root” de un contenedor privilegiado mapea a un UID sin privilegios en el host, lo que degrada bastante el impacto de un escape. Se instala con dockerd-rootless-setuptool.sh install.
No confíes el aislamiento de agentes de IA solo al plugin AuthZ. Sumá capas: usuario no root, filesystem de solo lectura, límites de recursos y capacidades recortadas (--cap-drop=ALL).

Para chequear rápido si tenés un plugin de autorización configurado, mirá la salida de docker info en la sección de plugins de autorización, o revisá si tu daemon arranca con --authorization-plugin.

Preguntas frecuentes

¿Qué versión de Docker parchea CVE-2026-34040?

Docker Engine 29.3.1 y superiores. Todas las versiones por debajo son vulnerables si hay un plugin AuthZ que inspecciona el cuerpo de las peticiones.

¿Cuál es la puntuación CVSS de esta vulnerabilidad?

8.8 (alta). Su antecesor CVE-2024-41110, del que es regresión, tenía la puntuación máxima de 10.0.

¿Soy vulnerable si no uso plugins de autorización?

No a este CVE en particular. El aviso oficial aclara que sin un plugin AuthZ activo no estás afectado. Aun así, conviene actualizar por prevención.

¿Se necesita código de exploit para aprovechar la falla?

No. Es una única petición HTTP con relleno para superar 1 MB, construible directamente desde la documentación de la API de Docker, sin herramientas especiales ni privilegios previos sobre el daemon vulnerable.

¿Cómo sé qué versión de Docker Engine tengo?

Ejecutá docker version y mirá el campo Server: Engine: Version. Si es menor a 29.3.1 y usás un plugin AuthZ, actualizá cuanto antes.

¿El modo rootless me protege por sí solo?

No lo elimina, pero reduce el impacto: un escape a “root” dentro del contenedor mapea a un UID sin privilegios en el host. Es mitigación, no reemplazo del parche.

Si querés blindar tu daemon más allá de este caso puntual, te sirven como lectura complementaria dos notas del blog: “Tu Docker asegurado: usuario no root, sistema de archivos de solo lectura y límites de recursos” (las capas que amortiguan un escape) y “Argo CD sin parche: RCE en repo-server toma tu cluster K8s” (otro caso reciente de cómo un componente sin actualizar compromete todo el clúster).

Fuentes: Cyera Research — One Megabyte to Root, The Hacker News, lilting.ch — análisis técnico del bypass y CSO Online.