Una vulnerabilidad en el kernel Linux ha vuelto a recordar una lección incómoda para administradores y equipos de ciberseguridad: los fallos más peligrosos no siempre son los más visibles. CVE-2026-31431, conocida como Copy Fail, permite a un usuario local sin privilegios escalar a root mediante una escritura controlada de 4 bytes en la caché de páginas del sistema. El problema afecta al subsistema criptográfico del kernel y tiene su origen en una optimización introducida en 2017, por lo que ha estado presente durante casi nueve años en kernels usados por distribuciones muy extendidas.
La vulnerabilidad fue divulgada públicamente el 29 de abril de 2026 por Theori, que la identificó con ayuda de Xint Code, su herramienta de análisis asistido por Inteligencia Artificial. Según el análisis técnico, el exploit no necesita condiciones de carrera, ajustes específicos por distribución ni recompilación. En las pruebas publicadas, un script de Python de apenas 732 bytes logró obtener privilegios de root en sistemas como Ubuntu, Amazon Linux, RHEL y SUSE.
Un fallo lógico en una zona poco esperada
Copy Fail no nace de un desbordamiento evidente ni de una mala validación trivial. El fallo aparece por la combinación de varias decisiones técnicas razonables por separado, pero peligrosas al interactuar entre sí. La pieza central está en algif_aead, el módulo que expone cifrados AEAD del kernel a espacio de usuario mediante la interfaz AF_ALG. Esta interfaz permite que procesos sin privilegios pidan al kernel operaciones criptográficas sobre datos.
El problema surge cuando esa ruta se combina con splice(), una llamada del sistema diseñada para mover datos entre descriptores de fichero y tuberías sin copias innecesarias. Al hacerlo, el kernel puede trabajar con referencias directas a páginas de la caché de archivos. En determinadas condiciones, el flujo criptográfico termina colocando páginas de la page cache dentro de una lista de destino que puede recibir escrituras.
El resultado es una primitiva pequeña, pero muy potente: un atacante local puede escribir 4 bytes controlados en una página cacheada de un archivo legible. Si el objetivo es un binario setuid, como /usr/bin/su, esa modificación en memoria puede alterar el comportamiento del programa y permitir la escalada a root. El archivo en disco no cambia, porque la página alterada no se marca como sucia para escritura posterior. Por eso las herramientas de integridad basadas en comparar el contenido almacenado en disco pueden no ver nada extraño.
Este detalle es especialmente delicado en análisis forense. Copy Fail no modifica necesariamente el binario persistente. Cambia la copia en memoria que el sistema usa al ejecutar o leer ese archivo mientras la página permanece en caché. No obstante, conviene matizar una idea: que el disco no refleje el cambio no significa que sea completamente invisible. Cloudflare, por ejemplo, explicó que el exploit deja una traza distintiva en los logs del kernel y que sus detecciones de comportamiento podían identificar el patrón en minutos.
Por qué afecta también a contenedores
Uno de los aspectos más preocupantes de Copy Fail es su impacto en entornos contenerizados. La caché de páginas es compartida por el host, no está aislada de forma estricta por contenedor. Eso significa que un proceso dentro de un contenedor vulnerable puede influir en páginas cacheadas que afectan al nodo completo. Theori lo describe como una primitiva de escape de contenedor y un vector de compromiso para nodos Kubernetes.
Para equipos que operan plataformas cloud, CI/CD runners, entornos multi-tenant o clusters Kubernetes, este punto cambia la prioridad de respuesta. No hablamos de una vulnerabilidad remota explotable directamente desde Internet, sino de una escalada local. Pero en sistemas donde se ejecuta código de usuarios, pipelines, cargas de terceros o contenedores poco confiables, “local” no significa “poco importante”. Muchas cadenas de ataque modernas empiezan con una ejecución limitada y terminan buscando una vía para escapar al host.
CERT-EU clasificó la vulnerabilidad como una escalada local de privilegios de severidad alta, con una puntuación CVSS 3.1 de 7,8 atribuida por kernel.org. Su aviso recomendó priorizar nodos Kubernetes y runners de CI/CD expuestos a cargas no confiables, además de aplicar actualizaciones de kernel en cuanto estén disponibles.
La mitigación temporal propuesta por CERT-EU consiste en deshabilitar de forma persistente el módulo algif_aead hasta instalar un kernel corregido. Según el aviso, esta medida no afecta a tecnologías habituales como dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS o SSH, aunque puede impactar en aplicaciones que usen explícitamente el motor afalg o sockets AF_ALG de forma directa.
El parche y la lección para los equipos de seguridad
El arreglo upstream consiste en revertir la optimización que permitía operar in-place en algif_aead. La entrada de NVD para CVE-2026-31431 recoge que el kernel volvió a operar out-of-place porque no había beneficio real en mantener esa complejidad cuando origen y destino proceden de mapeos distintos. El parche principal aparece asociado al commit a664bf3d603d, integrado en mainline el 1 de abril de 2026.
La publicación del exploit generó cierta tensión porque no todas las distribuciones tenían paquetes corregidos en el momento de la divulgación pública. CERT-EU señaló el 30 de abril que, en esa fecha, los parches de proveedores aún estaban pendientes en varias distribuciones importantes, aunque el arreglo ya estaba en el kernel mainline. Para administradores, la recomendación práctica es revisar los avisos del proveedor, actualizar el kernel en cuanto haya paquete disponible y aplicar mitigaciones temporales donde no sea posible reiniciar de inmediato.
Copy Fail también deja una discusión interesante sobre el papel de la Inteligencia Artificial en la investigación de vulnerabilidades. Theori afirma que el hallazgo fue asistido por IA, pero partió de una observación humana sobre la interacción entre el subsistema criptográfico de Linux y datos respaldados por la page cache. En otras palabras, la herramienta ayudó a ampliar el análisis, pero no reemplazó el criterio del investigador.
La lección más útil para entornos profesionales no es que “la IA descubrió un bug en una hora”. Esa lectura es demasiado simple. Lo relevante es que sistemas muy revisados, como el kernel Linux, pueden acumular riesgos en interacciones raras entre componentes legítimos. AF_ALG, splice(), page cache, scatterlists y optimizaciones de rendimiento no son piezas sospechosas por separado. El fallo aparece en la frontera entre ellas.
Para docencia en ciberseguridad, Copy Fail es un caso excelente. Permite explicar por qué las vulnerabilidades lógicas son tan difíciles de detectar, por qué la integridad en disco no basta para defender un sistema, por qué los contenedores no deben tratarse como una barrera absoluta y por qué el parcheo del kernel sigue siendo una disciplina crítica. También muestra que la superficie de ataque local importa mucho más de lo que sugiere la palabra “local”.
En servidores Linux, la respuesta no debería limitarse a actualizar cuando haya tiempo. Hay que inventariar kernels, priorizar sistemas con usuarios no confiables, revisar nodos de contenedores, validar mitigaciones, reiniciar de forma planificada y comprobar si existen señales de explotación. En plataformas grandes, la capacidad de desplegar kernels corregidos con rapidez puede marcar la diferencia entre una vulnerabilidad grave y una crisis operativa.
Copy Fail no es el primer fallo de escalada local importante en Linux y no será el último. Pero sí destaca por su fiabilidad, su antigüedad, su impacto en contenedores y su discreción frente a controles tradicionales de integridad. Nueve años después de la optimización que lo hizo posible, el caso recuerda que incluso las mejoras de rendimiento pueden dejar deudas de seguridad muy difíciles de ver.
Preguntas frecuentes
¿Qué es CVE-2026-31431 o Copy Fail?
Es una vulnerabilidad de escalada local de privilegios en el kernel Linux, situada en el módulo algif_aead del subsistema criptográfico. Permite a un usuario sin privilegios escribir 4 bytes controlados en la caché de páginas y usar esa primitiva para obtener root.
¿Es una vulnerabilidad remota?
No. Requiere acceso local o ejecución de código en el sistema afectado. Aun así, es grave en servidores multiusuario, contenedores, runners de CI/CD y nodos Kubernetes donde se ejecutan cargas no confiables.
¿Por qué no siempre la detectan las herramientas de integridad?
Porque la modificación se produce en la page cache, en memoria, y no necesariamente en el archivo persistente del disco. Las comparaciones de checksum sobre el archivo almacenado pueden no ver el cambio.
¿Qué deben hacer los administradores Linux?
Actualizar el kernel con los paquetes del proveedor en cuanto estén disponibles, priorizar entornos con cargas no confiables y aplicar mitigaciones temporales como deshabilitar algif_aead cuando no sea posible parchear de inmediato.
