732 bytes para root en cualquier Linux
El 29 de abril de 2026, Taeyang Lee de Theori publicó la divulgación completa de CopyFail (CVE-2026-31431): una vulnerabilidad de lógica en el kernel de Linux que permite a cualquier usuario local sin privilegios obtener acceso root completo. El exploit es público, funcional, pesa 732 bytes y solo requiere la biblioteca estándar de Python. No hay race conditions. No hay offset brute-force. Es determinista.
Lo encontró una IA. Xint Code, el escáner de vulnerabilidades de Theori, localizó el fallo en aproximadamente una hora con un único prompt de operador. El bug llevaba nueve años en producción.
CVE-2026-31431 — CVSS 7.8 (Alto). Afecta a todas las distribuciones principales de Linux con kernels lanzados o mantenidos desde 2017. El parche oficial es el commit a664bf3d603d (mainline 7.0). Si no puedes reiniciar, deshabilita algif_aead — pero en distribuciones RHEL-family el módulo está compilado en el kernel: usa grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init" y reinicia.
Cómo funciona el exploit
El ataque encadena tres subsistemas del kernel de Linux que, de forma individual, son completamente legítimos:
1. AF_ALG (algif_aead): La interfaz de sockets del subsistema criptográfico del kernel. Cualquier usuario sin privilegios puede abrir un socket AF_ALG / SOCK_SEQPACKET y acceder a operaciones AEAD (cifrado autenticado). Sin CAP_SYS_ADMIN. Sin privilegios especiales.
2. splice(): Una llamada al sistema de transferencia zero-copy que pasa páginas del page cache directamente entre descriptores de archivo, sin copiar datos. Eficiente. Y, en este contexto, peligrosa.
3. authencesn: La plantilla del kernel para IPsec con Extended Sequence Numbers. Durante el descifrado, escribe 4 bytes en dst[assoclen + cryptlen] como parte del reordenamiento de bytes ESN.
El fallo: Una optimización introducida en 2017 permitió que el scatterlist de destino del AEAD apunte a las mismas páginas que el origen (operación in-place). Cuando el atacante hace splice() de un archivo ejecutable con setuid (por ejemplo, /usr/bin/su) hacia el socket AF_ALG, las páginas del page cache de ese archivo terminan en el scatterlist de destino. La escritura de scratch de authencesn aterriza entonces en esas páginas — corrompiendo en memoria el binario privilegiado con 4 bytes controlados por el atacante.
El detalle crítico: La corrupción ocurre antes de que la verificación del tag de autenticación devuelva -EBADMSG. El descifrado falla, pero la página ya está modificada. No se requiere ningún descifrado exitoso.
El punto ciego forense: El kernel nunca marca la página corrupta como “sucia” para writeback. El archivo en disco permanece intacto. AIDE, Tripwire e inotify comprueban el SHA-256 del disco y no encuentran nada. La modificación vive solo en RAM y desaparece al reiniciar o cuando el kernel evicta la página. Un atacante profesional puede usar esto, hacer root, limpiar rastros y el único registro que queda son syscalls completamente normales: socket(), setsockopt(), splice(), sendmsg(), recvmsg().
Por qué Docker no te protege aquí
Existe un malentendido extendido sobre qué protege realmente un contenedor. Los contenedores Docker no son máquinas virtuales. Son procesos con namespaces y cgroups. Comparten el kernel del host.
Y comparten el page cache del kernel.
Esto no es una debilidad de implementación de Docker — es consecuencia directa del modelo arquitectónico. El page cache de Linux es una estructura global del kernel compartida entre todos los procesos del sistema, incluyendo todos los contenedores corriendo en el mismo nodo.
En un clúster de Kubernetes con workloads en contenedores Docker: si un atacante consigue acceso a cualquier pod — incluso uno de baja criticidad, incluso como usuario no privilegiado dentro del contenedor — puede ejecutar CopyFail contra el page cache del host. Puede corromper /usr/bin/su o cualquier binario setuid legible del host. El contenedor actúa como vector de entrada, no como barrera.
La Universidad de Toronto clasificó CopyFail explícitamente como LPE y container escape simultáneos. Microsoft Security Blog lo confirmó: “the page cache is shared across containers and the host”.
Esto no es un fallo de Docker. Es el límite estructural del modelo de contenedores sobre kernel compartido, y CopyFail lo expone de forma irreprochable.
El confinamiento que ofrece Firecracker
AWS Firecracker es un Virtual Machine Monitor (VMM) escrito en Rust (~83.000 líneas) que usa KVM para crear microVMs. Es lo que ejecuta AWS Lambda y AWS Fargate en producción.
La diferencia arquitectónica con Docker es radical:
| Dimensión | Docker (default) | Firecracker microVM |
|---|---|---|
| Frontera de seguridad | Namespaces + cgroups (software) | Virtualización por hardware (VT-x/AMD-V) |
| Kernel compartido | Sí — todos los contenedores | No — kernel de guest aislado por tenant |
| Page cache compartido | Sí | No |
| Syscalls expuestos al host | ~300+ | ~24 (whitelist seccomp del jailer) |
| Costo de escape | ~$10K–50K (LPE de kernel) | ~$250K–500K (escape de hypervisor) |
Cuando un tenant en Firecracker ejecuta CopyFail, corrompe páginas dentro del guest kernel de ese microVM. La frontera de hardware impide que esa corrupción cruce al kernel del host o a los guest kernels de otros tenants. El blast radius está contenido por física, no por política de software.
El jailer de Firecracker amplifica este aislamiento: arranca el proceso VMM dentro de un chroot, aplica namespaces de pid y red dedicados, y carga un filtro seccomp-BPF con ~24 syscalls whitelisted. La superficie de ataque del VMM en sí es radicalmente menor que la de QEMU (miles de dispositivos emulados vs. 5 dispositivos virtio).
Esto explica por qué AWS Lambda y Fargate no aparecen en los avisos de CopyFail. Sus workloads ya viven en microVMs con kernels separados.
Los unikernels: eliminación de la superficie, no contención
Si Firecracker contiene el daño, los unikernels van un paso más allá: eliminan la superficie de ataque por construcción.
Un unikernel compila la aplicación junto con únicamente los componentes del OS que necesita, produciendo una imagen bootable única que corre directamente sobre el hypervisor. No hay shell. No hay usuarios locales. No hay /usr/bin/su. No hay AF_ALG a menos que la aplicación específicamente requiera cifrado AEAD vía socket de kernel.
El stack de ejecución pasa de:
APLICACIÓN → DOCKER → OS COMPLETO → HYPERVISOR → HARDWARE
a:
APLICACIÓN → HYPERVISOR → HARDWARE
CopyFail en un unikernel: Un NGINX o Redis corriendo como Unikraft o Nanos no incluye el subsistema algif_aead. No hay AF_ALG. No hay binarios setuid. No hay usuarios. La CVE literalmente no tiene superficie sobre la que ejecutarse. No se trata de parchar — es de no haber compilado el código afectado.
Los números respaldan el argumento. NanoVMs documenta que su kernel Nanos tiene aproximadamente una décima parte del 1% de la superficie de ataque de Linux. Unikraft implementa ~160 syscalls de Linux (frente a los 450+ del kernel completo) y solo las que la aplicación necesita. La reducción de requisitos de compliance es concreta: 46% menos de requisitos STIG, 37% menos de requisitos OS SRG vs RHEL 7.
El ecosistema está madurando. Unikraft (proyecto CNCF) levantó $6M en 2026 con inversión de Vercel Ventures. Prisma corre su servicio serverless de Postgres sobre Unikraft en producción. Tarides integró Unikraft como backend para MirageOS en noviembre de 2025. NGINX, Redis, HAProxy y SQLite corren como unikernels en entornos de producción documentados.
El estado del arte del despliegue seguro en 2026
CopyFail no es un evento único. En 2025 se documentaron 16 container escapes. Los tres CVEs simultáneos de runc en noviembre de 2025 (race conditions de mount y symlink) mostraron que el modelo de kernel compartido produce vulnerabilidades críticas a ritmo sostenido. Los ataques a la cadena de suministro más que se duplicaron globalmente en 2025, con más de 454.000 paquetes maliciosos identificados en npm.
El estado del arte del despliegue seguro en 2026 combina capas complementarias:
Aislamiento por hardware (Firecracker + Kata Containers): La primera línea de defensa estructural. Kata 3.x con backend Firecracker es el estándar recomendado para workloads multi-tenant en Kubernetes. Cada pod vive en su propio microVM con kernel aislado.
Syscall filtering con eBPF (Falco, Tetragon): La única capa capaz de detectar CopyFail en runtime. Un socket AF_ALG / SOCK_SEQPACKET creado por un proceso no-root es una señal de baja tasa de falsos positivos — los consumidores legítimos de AF_ALG SEQPACKET son cryptsetup, veritysetup y systemd-cryptsetup. Tetragon puede bloquear la syscall en kernel space antes de que complete; Falco detecta y alerta. Sysdig Secure ya incluye la regla “AF_ALG Page Cache Poisoning” en su política de Runtime Behavioral Analytics.
Contenedores sin root (Podman 5.0, rootless containers): Si ocurre un escape, el atacante emerge como usuario sin privilegios en el host — reducción significativa del blast radius post-escape.
Supply chain con SLSA + Sigstore: La EU Cyber Resilience Act y el draft de FedRAMP rev.6 están haciendo mandatorio SLSA Level 3 + SBOM SPDX. Sigstore alcanzó SLA de producción en febrero de 2025. Un equipo puede implementar provenance Level 2 + signing con 1-2 días de ingeniería en GitHub Actions.
gVisor para workloads específicos: El Sentry de gVisor reimplementa ~274 syscalls de Linux en Go y solo hace 53 syscalls al kernel host. No es hardware isolation pero reduce drásticamente la superficie. DigitalOcean migró toda su App Platform a gVisor en 2026.
El nuevo estándar del despliegue
CopyFail es una ilustración perfecta de por qué el modelo de contenedores sobre kernel compartido tiene un techo estructural de seguridad. Nueve años de CVEs de container escape, y ahora un fallo que hace que el concepto mismo de “contenedor” sea irrelevante como frontera de seguridad — porque la corrupción ocurre en el page cache que el host y todos los contenedores comparten.
El nuevo estándar no va a ser “Docker + más seccomp + mejor IAM”. Va a ser aislamiento por hardware como baseline y reducción de superficie como filosofía de construcción. Firecracker + Kata Containers + Unikraft en esa dirección.
Los unikernels eliminan clases enteras de CVEs no parcheando más rápido, sino no compilando el código afectado. CopyFail requiere AF_ALG. AF_ALG no existe en un NGINX unikernel. Fin.
La adopción está en marcha. Las fuerzas que la aceleran — AI-assisted vulnerability discovery que encuentra bugs de 9 años en una hora, container escapes a ritmo de uno por mes, presión regulatoria de CRA y FedRAMP — no van a reducirse.
La pregunta para equipos de ingeniería y seguridad no es si migrar, sino cuándo y en qué orden.