Si usas Docker en tu servidor, revisa esto: una falla del kernel permite escapar de un contenedor y tomar control del host completo

Toda la promesa de seguridad de Docker se apoya en una idea simple: lo que pasa dentro de un contenedor se queda dentro del contenedor, aislado del resto del servidor. CVE-2026-31431, una vulnerabilidad conocida por el nombre "Copy-Fail", rompe exactamente esa promesa — y lo hace sin necesidad de que el contenedor corra en modo privilegiado ni de ninguna configuración fuera de lo común.

El problema vive en runc, el componente que en la práctica ejecuta los comandos dentro de cada contenedor Docker (es la pieza que usan tanto Docker como la mayoría de las plataformas de contenedores del mercado). Cuando ejecutas docker exec para correr un comando dentro de un contenedor ya activo, runc abre internamente una referencia especial a su propio binario a través de /proc/self/exe. La falla permite que un proceso con acceso de bajo privilegio, corriendo dentro del contenedor, corrompa deliberadamente la caché de páginas de memoria del kernel del servidor mientras eso ocurre — y en el momento exacto en que runc está leyendo su propio binario, el atacante logra sobrescribir ese binario en el host, no dentro del contenedor. El resultado práctico es que un proceso que se suponía debía estar completamente aislado termina modificando software que corre con privilegios de administrador en la máquina física o virtual real, no en la burbuja donde debería estar limitado.

Lo que hace esta falla más seria que muchas otras es justamente lo que no requiere: no hace falta que el contenedor esté configurado como "privilegiado" (una mala práctica conocida que muchos administradores ya saben evitar), ni ningún montaje de volumen fuera de lo normal. El vector de ataque funciona desde el acceso de bajo privilegio que cualquier proceso dentro de un contenedor ya tiene por diseño — exactamente el escenario que Docker está pensado para contener de forma segura.

La corrección no es un simple apt upgrade docker: el parche real vive en el kernel de Linux, en un commit específico (identificado como a664bf3d603d) que revierte una optimización que se había introducido en 2017 para un módulo criptográfico del kernel llamado algif_aead — esa optimización, pensada para mejorar rendimiento, es la que terminó abriendo la puerta a este tipo de corrupción de memoria casi una década después. Si tu distribución todavía no tiene ese parche disponible en su kernel, existe una mitigación más inmediata que no depende de esperar la actualización: deshabilitar el módulo vulnerable directamente.

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead

Este comando le dice al sistema que no cargue ese módulo específico, cerrando la vía de explotación mientras esperas a que tu distribución publique el kernel corregido — y una vez que sí lo actualices, no hace falta revertir este cambio, no tiene costo dejarlo así.

Si sigues las guías de esta serie y ya tienes Docker corriendo herramientas como n8n, PostgreSQL o incluso agentes de IA con acceso al socket de Docker —como el que cubrimos hace unos días—, esta es exactamente el tipo de falla que justifica por qué insistimos tanto en no correr contenedores de terceros sin revisar su origen, y en mantener el kernel de tu servidor actualizado con la misma disciplina que aplicas a Docker mismo. La ilusión de aislamiento que ofrece un contenedor es solo tan fuerte como el software del que depende para mantenerla — y ese software, como acabamos de ver, también tiene fallas que nadie descubre hasta que alguien las busca a propósito.