CVE-2026-31431 (Copy Fail) - Cómo lo mitigamos

La semana pasada se divulgó una escalada local de privilegios grave en el kernel Linux: CVE-2026-31431, apodada "Copy Fail". Afecta a una amplia variedad de versiones del kernel en distribuciones Linux modernas, y apareció un exploit público poco después de la divulgación.

Quiero ser claro sobre lo que ocurrió, lo que significa para Appbox y qué hemos hecho al respecto. Versión breve: gracias a cómo están construidos nuestros contenedores, las apps que se ejecutan con reasignación de espacios de nombres de usuario ya estaban protegidas contra que esto se convirtiera en root del host, incluso antes de desplegar los kernels parcheados. Ayer (4 de mayo de 2026), también realizamos un mantenimiento de emergencia para actualizar todos los servidores a un kernel parcheado, por lo que el fallo ya ha desaparecido por completo de nuestra flota.

¿Qué es "Copy Fail"?

CVE-2026-31431 es una falla en la API criptográfica AF_ALG del kernel. Al vincularse a un cifrado específico (authencesn(hmac(sha256),cbc(aes))) y abusar de la forma en que el kernel empalma páginas en un búfer temporal, un usuario local sin privilegios puede escribir fragmentos arbitrarios de 4 bytes directamente en la caché de páginas de archivos que no debería poder modificar, incluidos binarios SUID como /usr/bin/su.

Una vez que la copia de su en la caché de páginas se sobrescribe con un ELF malicioso diminuto, la siguiente invocación ejecuta el código del atacante como UID 0. Fin del juego para el host.

Para los detalles técnicos más minuciosos (desensamblado de shellcode, trazas de syscalls y todo lo demás), el análisis de Andrea Veri es excelente: CVE-2026-31431: Copy Fail vs. rootless containers. También hizo el trabajo de demostrar, con eBPF y pruebas de uid_map, exactamente lo que veremos a continuación: que los espacios de nombres de usuario neutralizan este exploit.

Por qué las apps de Appbox ya estaban mitigadas

El exploit depende de que setuid(0) otorgue realmente root del host. En un contenedor que se ejecuta con espacios de nombres de usuario habilitados, eso no es lo que ocurre.

Los espacios de nombres de usuario asignan el espacio de UID del contenedor a un rango de UID distinto (sin privilegios) en el host. Así que, cuando el exploit tiene éxito dentro del contenedor y setuid(0) devuelve éxito, la shell "root" resultante se asigna a un usuario normal sin privilegios del host, no a root real. El shellcode se ejecuta, el prompt cambia a #, pero en el host:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

Eso es todo. Sin acceso a archivos del host, sin /etc/shadow, sin root del host. El límite del espacio de nombres del contenedor impide que esto se convierta en una fuga a root del host.

A nivel de plataforma, cada Appbox tiene su propio daemon Docker iniciado con la reasignación de espacios de nombres de usuario habilitada. En pseudocódigo, se parece más a esto:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

Esa asignación está respaldada por un rango subordinado dedicado de UID/GID en el host:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

Además, las definiciones de apps todavía pueden sobrescribir explícitamente UsernsMode cuando una app necesita un tratamiento especial:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

Así que la forma precisa de describirlo es: la reasignación de espacios de nombres de usuario forma parte del valor predeterminado de la plataforma, y las excepciones por app son explícitas. Hay una pequeña cantidad de apps que necesitan configuraciones distintas porque exponen funcionalidades que requieren capacidades adicionales, y esos casos se gestionan por separado.

En otras palabras: para las apps que se ejecutan con la configuración normal reasignada, Copy Fail no podía convertir el compromiso de un contenedor en root del host.

Lo que todavía queríamos corregir

Los espacios de nombres de usuario detienen la fuga al host, pero no hacen desaparecer el fallo dentro del contenedor. Un atacante todavía podría escalar a "root del contenedor" dentro del límite de la app, lo cual, aunque contenido, sigue siendo una mala práctica operativa. El propio kernel era vulnerable, y queríamos eliminar esa vulnerabilidad.

En cuanto nos enteramos del fallo, empezamos de inmediato a evaluar nuestra exposición. Aunque la reasignación de espacios de nombres de usuario ya bloqueaba el lado de fuga al host del problema para nuestra configuración normal de apps, aun así queríamos eliminar el fallo subyacente del kernel lo antes posible.

Lo que hicimos ayer

El domingo por la noche programamos un mantenimiento de emergencia para el lunes 4 de mayo de 2026, la ventana más temprana en la que podíamos desplegar una actualización del kernel en toda la flota.

Durante la ventana:

• Todos los hosts se actualizaron usando los paquetes oficiales del kernel de Debian que contienen la corrección de "Copy Fail".
• El objetivo era simple: eliminar por completo la ruta vulnerable del kernel, no solo depender de nuestro aislamiento de espacios de nombres existente.

El mantenimiento está completo. Todos los hosts de Appbox ejecutan ahora un kernel parcheado.

Qué significa esto para ti

• No necesitabas hacer nada. Tus apps siguieron ejecutándose y cualquier breve interrupción durante la ventana de mantenimiento fue el único efecto visible para clientes.
• Incluso antes del parche de ayer, la reasignación de espacios de nombres de usuario significaba que este fallo no podía convertir el compromiso de una app normal en root del host. Ese es exactamente el tipo de escenario para el que existe este modelo de aislamiento.
• De aquí en adelante, nuestra política no cambia: los espacios de nombres de usuario siguen activados de forma predeterminada, y las muy pocas excepciones pasan por una revisión de seguridad adicional.

La perspectiva general

Esta es una de esas CVE en las que el titular ("escalada local de privilegios, exploit público, todos los kernels modernos afectados") suena catastrófico, y para muchos entornos multiusuario compartidos realmente lo fue. La razón por la que no fue catastrófico para nosotros es la misma por la que tomamos decisiones arquitectónicas hace años que a veces nos cuestan algo de compatibilidad: ejecutamos apps con el principio de mínimo privilegio integrado en la capa de contenedores, no añadido después.

La defensa en profundidad funciona de verdad. ¿Fallo en la capa del kernel? La capa de espacios de nombres lo detuvo. ¿Fallo en la capa de espacios de nombres? La reducción de capacidades y seccomp detienen la mayor parte. No pretendemos que ninguna capa individual sea perfecta; simplemente nos aseguramos de que siempre haya una siguiente capa.

Si tienes alguna pregunta sobre esto o sobre cómo están configuradas tus apps específicas, ponte en contacto con nosotros.

¿Tienes preguntas? Contáctanos en support@appbox.co o abre un ticket en billing.appbox.co.