Docker Engine 29.8.2: dos fallos de seguridad en contenedores que no puedes ignorar

Versión de seguridad de Docker Engine 29.8.2: cambios y acciones recomendadas

Docker Engine 29.8.2 es una versión de seguridad publicada el 30/09/2026 que parchea dos vulnerabilidades explotables sin acceso root: una omisión de TLS activada por DNS para descargas del registro (CVE-2026-92543) y la inyección de tramas forjadas en redes overlay cifradas de Swarm (CVE-2026-92542). Si ejecutas tu propio daemon de Docker, especialmente uno que descarga de registros privados, actualiza ya; los dos avisos se publicaron un día después, el 01/10/2026. Una advertencia inicial: esta versión tiene una regresión conocida en Swarm, detallada más abajo.

Ninguna fuente reporta explotación activa. La urgencia radica en la facilidad para alcanzar los fallos: ninguno requiere acceso privilegiado en el host objetivo.

Qué incluye Docker Engine 29.8.2 y por qué importa

El lanzamiento está documentado en las notas de versión oficiales, con la lista de cambios reflejada en la discusión moby/moby #53829. Corrige tres CVE:

Actualizaciones de componentes incluidos: BuildKit v0.33.1, binarios estáticos de containerd v2.3.6 y runc v1.5.2.

Las fuentes principales de los dos fallos destacados son los avisos GHSA-7cfq-22r6-qp73 y GHSA-6m9p-4h64-m6vh, ambos publicados el 01/10/2026.

Los dos fallos en un párrafo

El primer fallo permite que cualquier parte que controle las respuestas DNS en la red haga que tu daemon hable con un registro sin verificar certificados, exponiendo tus credenciales y abriendo la puerta a la sustitución de imágenes. El segundo permite que cualquier usuario sin privilegios en un nodo Linux de Swarm cree paquetes UDP que se cifran con los parámetros IPsec de un overlay y se inyectan como tramas en una red overlay cifrada, posiblemente en otro nodo.

Qué CVE aplica a cada configuración

No necesitas preocuparte por los tres por igual. Si no usas Swarm, CVE-2026-92542 no aplica en absoluto. Si solo descargas de registros públicos en redes que controlas totalmente, tu exposición a CVE-2026-92543 es limitada pero no cero. Si ejecutas nodos de Kubernetes con containerd y sin el motor de Docker, la actualización de Docker no te arregla nada; necesitas el aviso de containerd para CVE-2026-53493.

CVE-2026-92543: cómo una respuesta DNS desactiva el TLS en tus descargas del registro

Según el aviso, la causa raíz está en cómo el daemon decide si un host de registro cuenta como inseguro.

El bug de coincidencia de loopback, paso a paso

loadInsecureRegistries() tiene hardcodeados 127.0.0.0/8 y ::1/128 como CIDRs inseguros. Cuando el daemon comprueba si un hostname de registro es inseguro, isCIDRMatch resuelve todas las direcciones del hostname y devuelve true si alguna cae en la lista de CIDRs inseguros. Así, un conjunto de respuestas DNS con una IP de loopback más una IP controlada por el atacante basta para clasificar todo el hostname como inseguro.

Como el transporte vuelve a conectar al hostname, la conexión a la dirección del atacante se salta la verificación de certificados y puede recurrir a HTTP sin cifrar.

Exposición de credenciales vía X-Registry-Auth

Siguen dos consecuencias. Primero, el daemon envía la cabecera X-Registry-Auth con cada descarga autenticada, por lo que esas credenciales llegan al host del atacante con un certificado inválido y quedan expuestas. Segundo, una etiqueta de imagen confiable puede sustituirse por un manifiesto y capas controlados por el atacante en el almacén de imágenes.

Quién está más expuesto: runners de CI en redes compartidas o cloud, máquinas de desarrollo en redes no confiables y cualquier host cuyo resolutor, o el camino hacia él, no sea totalmente confiable.

Por qué revisar las configuraciones split-horizon y el DNS corporativo

Las configuraciones split-horizon pueden devolver legítimamente conjuntos de direcciones distintos según el origen de la consulta. Eso es operación normal, no un ataque. La pregunta es si un atacante puede influir en las respuestas que recibe tu daemon. Si el resolutor de tu daemon está dentro de tu propia red y lo controlas, tu riesgo es mucho menor que el de un runner de CI usando el DNS que le asigne su proveedor cloud.

Qué no mitiga, según el aviso:

• Eliminar entradas insecure-registries. Los CIDRs de loopback están codificados en duro.
• Usar un certificado CA confiable para el registro. No ayuda si el hostname puede resolver a loopback.
• Fijado por digest. Defensa en profundidad solo contra sustitución de imágenes; no hace nada contra la exposición de credenciales.

CVE-2026-92542: tramas forjadas en redes overlay cifradas de Swarm

GHSA-6m9p-4h64-m6vh describe un defecto en las reglas de firewall del driver overlay.

El defecto de marcado de cifrado

Las reglas de iptables que marcan los datagramas VXLAN para cifrado coinciden tanto con los datagramas legítimos enviados por el kernel como con los datagramas falsificados enviados desde procesos de usuario. Cualquier datagrama UDP enviado desde el espacio de nombres de red del host de un nodo de Linux Swarm, dirigido al puerto de la ruta de datos de Swarm y que comience con una cabecera VXLAN correspondiente al VNI de una red overlay cifrada a la que esté conectado un contenedor en ejecución, se cifra con los parámetros IPsec de esa red overlay.

El resultado: un usuario sin privilegios en un nodo Swarm puede inyectar fácilmente tramas Ethernet falsificadas en una red overlay cifrada de otro nodo. El perfil CVSS refleja esto: impacto alto en integridad y disponibilidad, ninguno en confidencialidad (CVSS 4.0 6.9, AV:L/PR:L).

Las versiones afectadas son <= 25.0.18 y desde 26.0.0 hasta 29.8.1. Se corrigió en 29.8.2 y v25.0.19.

La solución temporal oficial con iptables

El aviso ofrece una mitigación exacta, bloqueando que los procesos de usuario envíen UDP al puerto de la ruta de datos de Swarm:

iptables -I OUTPUT -p udp --dport "$(docker info --format '{{.Swarm.Cluster.DataPathPort}}')" -m owner --socket-exists -j DROP

Si no ejecutas Swarm, este CVE no te afecta. Omite esta sección por completo.

Comprueba si estás expuesto antes de actualizar

Comprobaciones de versión, CIDR y DNS

Revisa la versión del daemon, no la del cliente:

docker version --format '{{.Server.Version}}'

Lo que importa es la versión del servidor. Necesitas la 29.8.2.

Luego mira qué clasifica actualmente el daemon como registros inseguros:

docker info --format '{{json .RegistryConfig.InsecureRegistryCIDRs}}'

Si la salida incluye rangos de loopback, es lo esperado (están fijados en el código), pero significa que cualquier nombre de host de registro que resuelva a una dirección de loopback se trata como inseguro. Para cada nombre de host de registro del que haces pull, haz una comprobación puntual:

getent ahosts "$host"

Advertencia: las respuestas de DNS pueden cambiar entre comprobaciones. Esto confirma si eras vulnerable en ese momento, no si siempre lo fuiste.

Auditoría de runners de CI y Docker-in-Docker

Las configuraciones de CI a menudo fijan versiones de Engine o usan imágenes Docker-in-Docker, y esos son los hosts que realizan pulls autenticados en redes no confiables:

grep -rnE "docker:[0-9]+\.[0-9]+|docker-version|dind" .github/ .gitlab-ci.yml

Cada coincidencia es un host que debes actualizar o subir de versión.

Qué CVE aplican a tu configuración

Mitigaciones provisionales mientras planificas la actualización

Fijado de nombres de host de registro y restricciones de egreso

Para CVE-2026-92543, el aviso lista dos mitigaciones: fija el nombre de host del registro a su dirección esperada mediante DNS confiable o una entrada en el archivo hosts, y restringe el acceso de red saliente del daemon solo a endpoints de registro confiables. El fijado vía archivo hosts es lo más rápido de desplegar; el filtrado de egreso es el mejor control a largo plazo independientemente.

Bloqueo del puerto de la ruta de datos de Swarm

Para CVE-2026-92542, aplica la regla DROP iptables owner-match anterior en cada nodo Swarm de Linux.

Establece una fecha límite para cada solución temporal

Estas son mitigaciones parciales, no arreglos definitivos. Asigna una fecha límite a cada una en tu tracker y considera la actualización como la única remediación completa. Nota nuevamente lo que no funciona: editar insecure-registries (los CIDRs de loopback están codificados), intercambiar por una CA confiable o confiar en el fijado de digest para proteger credenciales. Los operadores siguen haciendo esas tres cosas porque suenan bien; el aviso las descarta explícitamente.

Cómo actualizar a 29.8.2 de forma segura

Actualización de paquetes Debian/Ubuntu

Si instalaste desde el repositorio apt de Docker:

sudo apt-get update && sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin
sudo systemctl restart docker

Reiniciando nodos Swarm uno a uno

Reinicia los nodos worker uno a uno y confirma que los servicios de superposición cifrados estén operativos antes de tocar el siguiente nodo. Esto importa más de lo habitual para esta versión, por razones cubiertas en la sección de regresiones abajo.

Binarios estáticos y la rama 25.0

Si instalas desde binarios estáticos, descarga los binarios 29.8.2 y reinicia el daemon. En la rama 25.0, la corrección llegó en v25.0.19 según el aviso principal. Según fuentes secundarias, el soporte de seguridad de la línea 25.0 finalizaría el 4 de diciembre de 2026, así que planifica tu salida de esa rama de todas formas.

No olvides BuildKit en builders separados

Los builders que corren a través del driver docker-container, builders remotos y builders de Kubernetes ejecutan su propio BuildKit. Pueden permanecer por debajo de v0.33.1 incluso después de la actualización de Engine. Verifica cada builder por separado.

Checklist post-actualización: caché, credenciales y verificación

Verifica que el parche esté aplicado en todos lados

• Cada host que hace pull de un registro privado reporta 29.8.2 desde docker version --format '{{.Server.Version}}'.
• Las imágenes de runner de CI y los servicios Docker-in-Docker están actualizados (la salida de grep anterior es tu lista de tareas).
• Cada builder de buildx reporta BuildKit v0.33.1 o posterior.

Purga la caché de builds contaminada

La actualización detiene nuevas contaminaciones de caché pero no deshace las anteriores. Purga la caché de builds después de actualizar, priorizando builders compartidos que ejecutaron builds de PRs fork:

docker builder prune

Decide sobre la rotación de credenciales de registro

GHSA-7cfq-22r6-qp73 lista la divulgación de credenciales vía X-Registry-Auth como un posible impacto. Las credenciales usadas por un daemon vulnerable haciendo pull de un registro privado deben tratarse como potencialmente divulgadas. Ninguna fuente obliga a la rotación, así que es tu decisión basada en el historial de exposición: si tu daemon hizo pull en redes cuyo DNS no podías confiar plenamente, la rotación es el default más seguro. Revisa ~/.docker/config.json en tus hosts runner para ver qué registros tienen credenciales almacenadas.

Hosts solo con containerd

Revisa los hosts que ejecutan containerd sin Docker contra el propio aviso de containerd para CVE-2026-53493.

Y cierra el círculo con las mitigaciones: cada una que hayas aplicado debe tener una fecha de fin o eliminarse.

Una regresión a vigilar: el bug Join/Leave de overlay en 29.8.2

Una palabra de precaución antes de reiniciar masivamente los nodos Swarm. Esta sección proviene de un análisis posterior de la comunidad y del seguimiento upstream, no de los avisos oficiales.

Síntomas y causa

El problema se registra en el repositorio upstream como moby/moby#53834 y está documentado en un post-mortem de la comunidad. Cuando el inicio de un contenedor falla después del Join del controlador overlay, se ejecuta un doble Leave que decrementa el recuento de endpoints por nodo. Tras N+1 fallos así, el sandbox overlay se destruye para los contenedores sanos en ese nodo, mientras docker ps sigue reportándolos como en ejecución. No se había publicado ninguna corrección hasta el 03/10/2026.

La secuencia de mitigaciones

Según el informe de campo: corrige primero el fallo de inicio (un conflicto de puerto es visible vía docker service ps --no-trunc), escala el servicio fallido a cero, luego systemctl restart docker y reinicia los contenedores sin política de reinicio.

La conclusión práctica coincide con el procedimiento de actualización ya descrito: no reinicies todos los nodos Swarm a la vez. Ir de forma escalonada, un nodo cada vez, limita el área de impacto de esta regresión igual que ocurre con la corrección del CVE.

Qué haríamos nosotros primero

Si ejecutas Docker en servidores que gestionas, el orden lógico es: revisar docker version --format '{{.Server.Version}}' en cada host, aplicar la regla de iptables en nodos Swarm y fijar nombres de host de registro en runners de CI hoy, actualizar a 29.8.2 nodo por nodo esta semana, purgar cachés de builds, y luego decidir sobre la rotación de credenciales. Las mitigaciones del aviso te compran días, no meses. La actualización es la solución.

Una nota sobre lecturas adicionales: ninguno de nuestros artículos actuales cubre con suficiente detalle las versiones de seguridad de Docker Engine, por lo que los avisos y las notas de la versión anteriores son las mejores referencias.

Preguntas frecuentes

¿Docker Engine 29.8.2 soluciona los problemas en clústeres de Kubernetes?

La mayoría de los nodos de Kubernetes ejecutan containerd sin el motor de Docker. Una actualización de Docker no les sirve para CVE-2026-53493, cuyo aviso está en el repositorio de containerd; revisa las versiones corregidas de containerd. CVE-2026-92542 solo aplica a Swarm.

¿Debo rotar las credenciales del registro tras aplicar el parche?

La divulgación de credenciales mediante X-Registry-Auth es un impacto posible declarado de CVE-2026-92543, por lo que las credenciales usadas por un daemon vulnerable al descargar de un registro privado deben tratarse como potencialmente expuestas. Ninguna fuente obliga a rotarlas; decide según si tu daemon descargó en redes cuyo DNS no podías confiar plenamente.

¿Mi caché de compilación está segura tras actualizar?

No. La actualización detiene nuevos envenenamientos de caché, pero no deshace los anteriores. Limpia la caché de compilación, priorizando builders compartidos que ejecutaron builds de pull requests procedentes de forks, y verifica que cada builder informe de BuildKit v0.33.1 o posterior.

¿Hay explotación activa de estas vulnerabilidades de Docker?

Ninguna fuente reporta explotación en entornos reales. CVE-2026-92543 no tiene puntuación EPSS ni aparece en el catálogo KEV de CISA, lo que significa que la probabilidad es desconocida, no baja. La urgencia proviene de exploits que no requieren acceso privilegiado.

¿Qué pasa si no ejecuto Docker Swarm?

CVE-2026-92542 no aplica. Tu exposición es CVE-2026-92543 (descargas del registro sobre DNS que no controlas) y, en hosts solo con containerd, CVE-2026-53493 mediante su propio aviso.