- CopyFail (CVE-2026-31431) permite a un usuario local sin privilegios escalar a root en la mayoría de distribuciones Linux.
- El fallo afecta al subsistema criptográfico AF_ALG/algif_aead y authencesn y corrompe la caché de página sin tocar el disco.
- Servidores compartidos, Kubernetes, CI/CD y nubes públicas en Europa y España se consideran especialmente expuestos.
- La mitigación pasa por actualizar el kernel, desactivar algif_aead y limitar AF_ALG con seccomp/AppArmor/SELinux mientras llegan los parches.
La aparición de CVE-2026-31431, más conocida como CopyFail, ha encendido todas las alarmas en el ecosistema Linux. No estamos ante un fallo teórico ni difícil de explotar: un usuario local sin privilegios puede convertirse en root con un script diminuto, fiable y difícil de rastrear, algo especialmente delicado en servidores compartidos, nubes públicas y clústeres de contenedores que se usan a diario en España y el resto de Europa.
Esta vulnerabilidad afecta al kernel de Linux desde 2017 y ha pasado desapercibida durante casi una década, infiltrándose en prácticamente todas las distribuciones modernas. Su impacto es claro: si alguien consigue ejecutar código en un sistema vulnerable —ya sea a través de una web con fallo, una cuenta de usuario o un contenedor— puede usar CopyFail para escalar a superusuario y tomar el control total de la máquina.
Qué es CopyFail (CVE-2026-31431) y dónde reside el problema
CopyFail está catalogada como vulnerabilidad de escalada local de privilegios. No abre por sí sola una puerta desde Internet, pero convierte cualquier acceso local limitado en un billete directo a root. Esto incluye desde una cuenta sin privilegios en un servidor dedicado hasta un proceso dentro de un contenedor Docker o un pod de Kubernetes que comparta kernel con el host.
El fallo se encuentra en el subsistema criptográfico del kernel, concretamente en la interfaz AF_ALG/algif_aead y en la plantilla authencesn utilizada para operaciones AEAD. Un cambio de optimización introducido en 2017 para hacer estas operaciones «in-place» —es decir, reutilizando el mismo búfer de memoria— terminó creando una condición peligrosa: una escritura fuera de límites de 4 bytes en la caché de páginas de Linux.
Según el análisis publicado por equipos como Xint/Theori y otras firmas europeas, la vulnerabilidad permite al atacante forzar una escritura controlada de 4 bytes sobre la copia en memoria de un archivo, sin que el fichero almacenado en disco se vea alterado. El resultado práctico es que se puede modificar en RAM un binario con bit setuid, como /usr/bin/su o sudo, y conseguir que, al ejecutarse, brinde una shell con privilegios de administrador.
Todo esto se hace usando llamadas al sistema completamente legítimas: sockets AF_ALG y la syscall splice(). El truco está en cómo se combinan estas piezas para que el kernel vincule el búfer de destino criptográfico directamente con páginas de la caché de archivos, algo que la optimización de 2017 facilitó sin prever sus consecuencias de seguridad.
Cómo funciona el exploit: cuatro bytes en la caché que cambian todo
Los investigadores describen CopyFail como un bug lógico, no una típica carrera de memoria llena de condiciones aleatorias. Ese matiz explica por qué el exploit es tan estable: el mismo script de unos 732 bytes en Python ha demostrado funcionar sin modificaciones en distintas distribuciones como Ubuntu, Debian, SUSE, RHEL, Amazon Linux o incluso entornos WSL2 sobre Windows.
El ataque se apoya en la interfaz AF_ALG, que permite a programas de espacio de usuario usar el motor criptográfico del kernel sin permisos especiales. El exploit abre un socket AF_ALG, selecciona el modo AEAD vulnerable y luego utiliza splice() para acoplar páginas de la caché de un ejecutable setuid (por ejemplo, /usr/bin/su) al flujo de datos que el kernel tratará como destino de una operación criptográfica.
Durante esa operación, el algoritmo authencesn reorganiza datos y acaba escribiendo 4 bytes fuera del área prevista, pero dentro de la misma página de caché. Como esa página corresponde al binario elegido, el atacante consigue corromper de forma precisa cuatro bytes de la versión en memoria del ejecutable. Repitiendo la técnica con distintos offsets y valores, se pueden modificar instrucciones clave hasta lograr que el programa otorgue una shell de root.
El detalle más inquietante es que la modificación nunca llega al disco. La página de caché alterada no se marca como «sucia», de modo que el kernel no escribe esos cambios en el archivo físico. Un reinicio o una recarga desde disco limpian el rastro del ataque, lo cual dificulta mucho la labor forense y deja a los antivirus tradicionales sin pistas, ya que las comprobaciones basadas en hashes de archivos en reposo no detectan nada extraño.
Además, al utilizar llamadas estándar como socket(AF_ALG), splice() o execve() de binarios habituales, la actividad del exploit se confunde con el ruido normal del sistema. No requiere adivinar direcciones de memoria ni explotar carreras difíciles, lo que rebaja la barrera técnica para posibles atacantes y hace que el código de explotación sea compacto, fiable y fácil de integrar en cadenas de ataque más amplias.
Qué sistemas Linux están afectados y cómo de grave es el fallo
Los informes técnicos coinciden en que la mayoría de kernels Linux compilados desde 2017 hasta la inclusión del parche oficial son vulnerables si incorporan el soporte para AF_ALG y el módulo algif_aead. Eso incluye a las grandes familias de distribuciones que se usan masivamente en Europa:
- Ubuntu LTS (16.04 a 26.04), con múltiples sabores de kernel (incluidos paquetes HWE y variantes para IBM o cloud) que han ido recibiendo parches en oleadas, dejando algunos paquetes antiguos sin corrección por fin de soporte.
- Debian en sus ramas bullseye, bookworm y trixie, con versiones de kernel 5.10.x y 6.1.x marcadas como vulnerables mientras se completaban los backports de seguridad.
- Red Hat Enterprise Linux (RHEL) y SUSE, muy presentes en centros de datos europeos y sistemas críticos, con kernels donde AF_ALG puede estar compilado directamente en el núcleo, lo que complica deshabilitarlo sin actualizar.
- Amazon Linux 2 y Amazon Linux 2023, bases habituales en instancias EC2 y nodos de EKS en proveedores de nube también usados en España, con versiones 5.4, 5.10, 5.15, 6.12 y 6.18 afectadas en distintos momentos.
- Entornos WSL2 en estaciones de trabajo, donde el kernel Linux proporcionado por Microsoft también integra el soporte afectado y comparte riesgos similares a los de un servidor tradicional.
En cuanto a la severidad, distintos fabricantes han asignado a CopyFail una puntuación CVSS en torno a 7,8/10, lo que la sitúa en categoría de «alto». La clave es que, aunque requiere ejecución local, convierte casi cualquier acceso al sistema en un compromiso total del host. En entornos multiusuario, con contenedores o con servicios que ejecutan código de terceros (como CI/CD o plataformas de desarrollo), esa condición deja de ser un consuelo.
Otro punto delicado es la coordinación de la divulgación. El fallo fue reportado con antelación al equipo de seguridad del kernel de Linux, y las ramas oficiales ya contaban con correcciones en versiones como 7.0, 6.19.12, 6.18.12, 6.12.85, 6.6.137, 6.1.170, 5.15.204 y 5.10.254. Sin embargo, muchas distribuciones aún no habían integrado esos parches cuando se publicó el exploit, lo que dejó a miles de sistemas europeos en una situación muy similar a un zero-day a ojos de los administradores.
Impacto en servidores, cloud y contenedores en España y Europa
El riesgo real de CopyFail se dispara en arquitecturas modernas, donde varios clientes o servicios comparten el mismo kernel. En el contexto español y europeo, esto afecta de lleno a:
- Servidores compartidos y proveedores de hosting, donde distintas webs de empresas y administraciones conviven en el mismo nodo físico.
- Clústeres de Kubernetes utilizados por grandes corporaciones, startups tecnológicas y organismos públicos para desplegar microservicios.
- Runners de CI/CD en plataformas como GitHub Actions, GitLab, Jenkins o soluciones on-premise, que ejecutan código no confiable enviado por desarrolladores o terceros.
- Plataformas cloud y VPS multi-tenant ofrecidos por proveedores europeos y globales, donde muchos clientes comparten infraestructura subyacente.
- Entornos de desarrollo internos con múltiples cuentas de usuario, desde universidades hasta centros de investigación y empresas de software.
En todos estos casos, un atacante que consiga un acceso inicial limitado —por ejemplo, a través de una vulnerabilidad en una aplicación web o de unas credenciales filtradas— puede usar CopyFail para saltar a root y, desde ahí, romper el aislamiento lógico entre usuarios, contenedores y servicios. Eso abre la puerta a leer datos de otros clientes, desplegar puertas traseras persistentes o pivotar hacia otras máquinas dentro de la misma red.
Investigadores han demostrado incluso la posibilidad de escapar de contenedores Kubernetes aprovechando que todos comparten la misma caché de páginas del host. Una vez comprometido el nodo, es perfectamente viable tomar el control del clúster completo, algo especialmente preocupante en organizaciones europeas que gestionan servicios críticos de salud, banca o telecomunicaciones sobre estas plataformas.
En entornos como WSL2, muy utilizados por desarrolladores en España, CopyFail también plantea un problema: un proceso aparentemente inocuo dentro del subsistema Linux puede elevar privilegios dentro del kernel y facilitar movimientos laterales hacia otros recursos de la máquina si no existen medidas de segmentación adecuadas.
Descubrimiento, papel de la IA y debate sobre la gestión del fallo
Uno de los aspectos más comentados de CopyFail es que el bug llevaba activa desde 2017 y nadie lo había detectado, pese a los exhaustivos análisis a los que se somete el kernel de Linux. El hallazgo llegó gracias a herramientas de análisis de código apoyadas en inteligencia artificial, como Xint Code, utilizadas por investigadores de empresas como Theori y Xint.
Estas herramientas automatizadas escanean millones de líneas de código buscando patrones anómalos, interacciones peligrosas entre funciones y combinaciones poco exploradas de llamadas al sistema. En este caso, el foco se puso en la superficie de ataque del subsistema criptográfico, especialmente en la interacción de splice() con la caché de páginas y las estructuras scatterlist usadas por AF_ALG.
En cuestión de aproximadamente una hora de análisis, el sistema de IA señaló la escritura fuera de límites en authencesn y cómo podía terminar modificando páginas de la caché asociadas a archivos accesibles por el usuario. A partir de ahí, los investigadores desarrollaron un exploit funcional capaz de obtener un shell de root en distintas distribuciones sin ajustes específicos.
La divulgación del fallo, no obstante, no ha estado exenta de polémica. Algunos expertos en respuesta a vulnerabilidades han criticado que se hiciera público el exploit cuando varias distribuciones todavía no habían integrado los parches, generando un efecto de «zero-day práctico» para muchos administradores. Otros, en cambio, argumentan que este tipo de presión acelera las actualizaciones y pone de manifiesto la importancia de no retrasar la aplicación de parches del kernel.
Lo indiscutible es que CopyFail ilustra bien la tendencia de los últimos años: optimizaciones de rendimiento del kernel que terminan abriendo vectores de ataque inesperados. Vulnerabilidades anteriores como Dirty Cow o Dirty Pipe ya mostraron esta tensión entre eficiencia y seguridad; CopyFail se suma ahora a esa lista, pero centrado en el subsistema criptográfico.
Medidas de mitigación y parches disponibles para CopyFail
La solución de fondo para CopyFail pasa por actualizar el kernel de Linux a una versión que incluya la corrección oficial. El cambio clave, identificado en las ramas estables como el commit a664bf3d603d y otros parches relacionados, revierte la optimización «in-place» problemática en algif_aead y separa adecuadamente los búferes de origen y destino para evitar que las páginas de caché terminen en rutas escribibles.
Los mantenedores del kernel han integrado estos parches en versiones como kernel 7.0 y en actualizaciones de las ramas 6.19, 6.18, 6.12, 6.6, 6.1, 5.15 y 5.10, mientras que las distribuciones están adaptando los cambios a sus kernels LTS. En el caso de Ubuntu, Debian, SUSE, RHEL o Amazon Linux, los boletines de seguridad van marcando qué versiones del kernel están ya protegidas y cuáles siguen pendientes.
Mientras no sea posible reiniciar y actualizar, se recomiendan varias mitigaciones temporales:
- Desactivar el módulo algif_aead mediante reglas de modprobe (por ejemplo, añadiendo entradas en /etc/modprobe.d/ para bloquear su carga) y descargándolo con rmmod si está presente.
- Restringir la creación de sockets AF_ALG con políticas de seguridad como seccomp, AppArmor o SELinux, de forma que procesos sin privilegios no puedan acceder a la API criptográfica del kernel.
- Limitar o desactivar el uso de AF_ALG en cargas de trabajo no confiables, especialmente en contenedores que ejecutan código enviado por terceros o en runners de CI/CD.
- Revisar el inventario de binarios setuid y reducirlo al mínimo imprescindible, para disminuir las opciones de escalada si un atacante consigue corromper uno de ellos.
En algunos entornos, como Android moderno, las políticas estrictas de SELinux y la ausencia de AF_ALG accesible han servido como escudo natural frente a este tipo de ataque. Para servidores y sistemas de propósito general usados en empresas europeas, replicar estrategias de endurecimiento similares puede marcar la diferencia cuando surgen vulnerabilidades de este calibre.
Detección y monitorización: cómo buscar rastros de CopyFail
Aunque CopyFail manipula solo la memoria y deja intactos los archivos en disco, es posible vigilar patrones de comportamiento sospechosos relacionados con su explotación. Herramientas como auditd, soluciones EDR avanzadas y plataformas SIEM permiten construir reglas específicas para identificar posibles intentos de ataque.
Entre las recomendaciones de distintos fabricantes de seguridad destacan:
- Monitorizar el uso de splice() por parte de usuarios no privilegiados cuando intervienen descriptores de archivos asociados a binarios con bit setuid.
- Registrar la creación de sockets con familia AF_ALG (valor 26 en decimal) desde cuentas de usuario normales (UIDs mayores o iguales a 1000) o desde intérpretes como Python.
- Vigilar accesos de lectura a binarios setuid como su, sudo, passwd, gpasswd, newgrp, chfn, chsh, mount, umount o fusermount3, cuando provienen de rutas poco habituales o de scripts que después lanzan una shell.
- Detectar cadenas de comandos atípicas del estilo «python … su» o «sh -c — su» en sistemas que no usan este tipo de invocaciones en su operativa normal.
Fabricantes de EDR han incorporado reglas con nombres como possible_lpe_by_python o possible_copy_fail_cve_2026_31431, centradas en la correlación de llamadas al sistema y cambios inesperados de UID dentro de la misma cadena de procesos. Aunque ninguna detección es infalible, este tipo de vigilancia ayuda a acotar la ventana de tiempo entre un intento de explotación y su identificación.
Para organizaciones con infraestructuras complejas —banca, industria, sector público—, lo recomendable es enviar estos eventos a un SIEM centralizado y configurar alertas que disparen investigaciones rápidas cuando se detecten patrones compatibles con CopyFail. De este modo, incluso si el exploit falla o no llega a completar la escalada, quedará un rastro útil para el equipo de seguridad.
Lecciones para empresas y administraciones que dependen de Linux
CopyFail llega en un momento en el que Linux sostiene buena parte de la economía digital europea: desde servidores web y plataformas de comercio electrónico en España hasta sistemas de backoffice bancario, infraestructuras de telecomunicaciones y entornos de investigación científica. Un bug relativamente pequeño en el subsistema criptográfico ha demostrado ser suficiente para poner contra las cuerdas ese andamiaje.
Para las organizaciones, la primera prioridad es clara: inventariar todos los sistemas Linux, comprobar la versión del kernel y aplicar los parches proporcionados por cada distribución tan pronto como sea posible. En los entornos donde el reinicio sea más delicado, conviene al menos desplegar mitigaciones sobre los nodos más expuestos, como servidores accesibles desde Internet, clústeres multiusuario y nodos de Kubernetes con cargas no confiables.
A medio plazo, CopyFail refuerza varias ideas que el sector de la ciberseguridad lleva tiempo repitiendo: no retrasar las actualizaciones del kernel por miedo a «romper producción», endurecer las políticas de seguridad en torno a interfaces sensibles como AF_ALG, reducir la dependencia de binarios setuid y apostar por herramientas de análisis —incluida la IA— que ayuden a encontrar fallos lógicos antes de que los descubra alguien con malas intenciones.
La combinación de un exploit pequeño, multiplataforma y difícil de detectar, junto a la presencia masiva de kernels vulnerables en servidores y contenedores, convierte a CopyFail en un recordatorio incómodo pero útil: incluso en un sistema tan auditado como Linux, un descuido en una optimización puede convertirse en un problema global si no se mantiene una disciplina férrea de actualización, mitigación y monitorización continua.
