Copy Fail: la vulnerabilidad de Linux que pone en jaque a servidores y nubes

Trucoteca » Otros » Copy Fail: la vulnerabilidad de Linux que pone en jaque a servidores y nubes

La comunidad de software libre y administradores de sistemas Linux en Europa está lidiando estos días con un problema que va bastante más allá de un parche rutinario. Copy Fail, registrada como CVE-2026-31431, ha destapado un fallo en el núcleo de Linux que llevaba años escondido y que permite a cualquier usuario local sin privilegios acabar controlando la máquina con permisos de root.

Su impacto se nota ya en centros de datos europeos, clústeres de Kubernetes, plataformas de CI/CD y servicios cloud que ejecutan código de terceros. Aunque Copy Fail no abre por sí misma una puerta desde Internet, convierte casi cualquier pequeña intrusión local —desde una cuenta comprometida hasta un contenedor mal aislado— en una escalada de privilegios muy fiable y difícil de rastrear.

Qué es Copy Fail (CVE-2026-31431) y por qué preocupa tanto

Copy Fail es una vulnerabilidad de escalada local de privilegios (LPE) en el kernel de Linux. En la práctica, permite que un usuario con una cuenta normal, un proceso dentro de un contenedor o un job de CI sin permisos administrativos termine ejecutando código como root en sistemas vulnerables.

El fallo está registrado como CVE-2026-31431 y afecta al subsistema criptográfico del kernel, en concreto a la interfaz AF_ALG expuesta a espacio de usuario y al módulo algif_aead, que se apoya en la plantilla criptográfica authencesn. Esta combinación acaba permitiendo escribir 4 bytes controlados por el atacante dentro de la page cache, la caché de páginas donde Linux guarda copias en RAM de los archivos.

Investigadores de Xint Code y Theori publicaron a finales de abril de 2026 un exploit de apenas 732 bytes en Python capaz de explotar el fallo de forma estable en entornos convencionales. No depende de condiciones de carrera complicadas ni de configuraciones exóticas, lo que sitúa a Copy Fail en la liga de las vulnerabilidades locales más serias de los últimos años.

En el contexto europeo, donde Linux es omnipresente en bancos, operadoras, administraciones públicas y proveedores cloud, la combinación de exploit diminuto, alta fiabilidad y dificultad de detección ha disparado las alarmas. CERT-EU ha emitido alertas urgentes pidiendo revisar nodos de Kubernetes, runners de CI/CD y servidores multiusuario lo antes posible.

El origen del fallo: una optimización de 2017 que salió cara

La raíz técnica de Copy Fail se remonta a una optimización introducida en 2017 en el kernel de Linux, identificada en múltiples análisis como un commit que modificó el comportamiento de algif_aead para hacer operaciones «in-place». La idea era sencilla: reducir copias de memoria en el subsistema criptográfico para ganar rendimiento.

Ese cambio afectó a la plantilla authencesn, que combina HMAC-SHA256 con AES-CBC. Durante ciertas operaciones AEAD, parte del búfer de salida se reutiliza como zona de trabajo temporal. El problema es que, en esa reorganización de datos, el algoritmo acaba realizando una escritura de 4 bytes fuera de los límites previstos del búfer de salida.

En condiciones normales, ese pequeño desbordamiento podría pasar desapercibido. Pero combinado con la llamada al sistema splice(), que transfiere referencias de la page cache a descriptores de archivo en espacio de usuario, esos 4 bytes terminan cayendo directamente sobre la copia en memoria de un archivo del sistema, incluyendo binarios marcados como setuid que se ejecutan con privilegios de superusuario.

El parche oficial que corrige CVE-2026-31431 revierte precisamente esa optimización peligrosa, separando de nuevo las áreas de memoria de origen y destino y reforzando la validación de buffers. En las ramas estables del kernel el cambio se ha asociado a commits como a664bf3d603d, que se están integrando mediante backports en versiones de soporte prolongado.

Cinco claves del funcionamiento del exploit

El mecanismo de ataque descrito por Xint/Theori y otras firmas de seguridad se apoya en interfaces del kernel que suelen venir activadas por defecto. De forma simplificada, la explotación de Copy Fail sigue un flujo como este:

• El atacante abre un socket AF_ALG desde espacio de usuario y selecciona el modo AEAD vulnerable proporcionado por el módulo algif_aead.
• Mediante la llamada splice(), enlaza páginas de la caché de un archivo legible (por ejemplo, /usr/bin/su) con el búfer de destino que el kernel usará para la operación criptográfica.
• Durante el procesamiento, debido al bug lógico en authencesn, el kernel realiza una escritura de 4 bytes fuera de los límites del búfer de salida previsto.
• Esa escritura cae sobre la página de la caché que contiene parte del código del binario con setuid, y su contenido queda controlado por el atacante a través de los parámetros de la operación y los datos adicionales autenticados (AAD).
• Repitiendo el ciclo, se pueden ir modificando pequeñas porciones del binario en memoria hasta lograr que, al ejecutarse, otorgue una shell con privilegios de root.

La gran ventaja para el atacante es que todo esto ocurre únicamente en la page cache del kernel. El archivo en disco no se modifica, así que las herramientas de integridad basadas en hashes o firmas siguen viendo el binario como legítimo.

Por si fuera poco, la página de caché alterada no se marca como «sucia», por lo que el kernel no tiene motivo para escribir de vuelta los cambios al disco. Un simple reinicio o cierta presión de memoria que fuerce la recarga del archivo desde almacenamiento hace que la modificación desaparezca sin dejar huella visible.

Una vulnerabilidad sigilosa: memoria alterada, disco intacto

Uno de los aspectos más inquietantes de Copy Fail es su carácter volátil y difícil de rastrear. Al atacar únicamente la caché de páginas en RAM, sin tocar el contenido persistente, el fallo esquiva muchas de las defensas clásicas en servidores Linux.

Las comprobaciones periódicas de integridad que se basan en comparar hashes de archivos del sistema con una referencia conocida no detectan nada extraño, porque el contenido físico en disco no cambia. El binario de /usr/bin/su en el sistema de archivos sigue siendo idéntico al original, mientras que la versión en memoria puede estar parcialmente manipulada.

Desde el punto de vista de un análisis forense posterior, esto supone un reto evidente. Si el sistema se reinicia o la caché se invalida por cualquier motivo, la variante corrupta en memoria se pierde. Sin logs ni capturas de memoria, reconstruir lo que ha ocurrido resulta complicado, incluso para equipos de respuesta a incidentes con experiencia.

Además, el exploit utiliza llamadas al sistema perfectamente legítimas: creación de sockets AF_ALG, uso de splice(), ejecución de binarios setuid como su o sudo. Todo ello se mezcla con la actividad normal del sistema, de modo que sin reglas de monitorización específicas es fácil que pase desapercibido.

Sistemas y distribuciones afectadas: impacto en España y Europa

Los análisis coinciden en que Copy Fail afecta a la mayoría de kernels Linux distribuidos desde 2017 que incluyen la optimización problemática en algif_aead y tienen habilitado el soporte para AF_ALG. En la práctica, esto se traduce en un alcance muy amplio.

Entre las plataformas afectadas se encuentran Ubuntu, Debian, Red Hat Enterprise Linux (RHEL), SUSE, Amazon Linux y diversas compilaciones utilizadas en WSL2. En el caso de Ubuntu, los avisos de seguridad marcan como vulnerables múltiples ramas LTS y kernels HWE, con prioridad alta y varios paquetes en estado «fix pending» en los primeros días tras la divulgación.

Amazon Linux 2 y Amazon Linux 2023 —muy presentes en instancias EC2 y nodos EKS desplegados en regiones europeas— figuran con kernels 5.4, 5.10, 5.15, 6.12 y 6.18 afectados hasta la llegada de sus correspondientes parches. Debian ha señalado versiones de bullseye, bookworm y trixie con ramas 5.x y 6.x dentro del rango vulnerable.

La vulnerabilidad ha recibido una puntuación CVSS en torno a 7,8/10, lo que la sitúa en la categoría de alta gravedad. No es un ataque remoto universal, pero su capacidad para convertir un acceso local limitado —por ejemplo, a través de SSH o de un script de CI— en control total del sistema la convierte en un riesgo especialmente serio para infraestructuras críticas europeas.

Copy Fail en servidores, contenedores y entornos cloud

Donde Copy Fail muestra su cara más problemática es en los entornos multi-tenant y de ejecución de código de terceros, muy habituales en empresas españolas y europeas que han apostado por la nube y la contenedorización.

En un proveedor de hosting compartido, un único cliente con una cuenta de usuario podría aprovechar un fallo menor en su propia aplicación web para conseguir ejecución de código local y, a partir de ahí, utilizar Copy Fail para comprometer el servidor físico que aloja a muchos otros clientes. Una vez con acceso root al host, la separación entre cuentas deja de existir.

En clústeres de Kubernetes, el problema es similar. Todos los pods de un nodo comparten el mismo kernel y la misma caché de páginas. Un atacante que logre ejecutar el exploit desde un contenedor con pocos privilegios puede romper el aislamiento del contenedor, tomar el control del nodo host y moverse lateralmente hacia otros pods o incluso hacia el plano de control si la configuración lo permite.

Los runners de CI/CD (GitHub Actions, GitLab, Jenkins o soluciones internas) que compilan y prueban código de múltiples proyectos también están en el punto de mira. Un pipeline mal protegido, un repositorio con código malicioso o un script inyectado pueden convertirse en la puerta de entrada para escalar a root en la máquina que ejecuta los jobs.

Este tipo de escenarios encaja con la realidad de muchas organizaciones europeas: bancos que ejecutan cientos de pipelines diarios, startups que dependen de proveedores cloud para sus despliegues o administraciones públicas con clústeres híbridos en centros de datos propios y nubes externas. En todos esos casos, CVE-2026-31431 fuerza a revisar sin demora el estado de los kernels.

Comparación con otras vulnerabilidades del kernel: Dirty COW, Dirty Pipe y compañía

Copy Fail no llega en un vacío. En la última década se han hecho célebres otras vulnerabilidades del kernel de Linux como Dirty COW (CVE-2016-5195) o Dirty Pipe (CVE-2022-0847), que también aprovecharon la gestión interna de la page cache y de las operaciones de E/S para modificar datos teóricamente solo de lectura.

La gran diferencia es que, mientras estos fallos se centraban más en lograr escritura arbitraria en archivos o en tuberías, Copy Fail actúa casi exclusivamente sobre la versión en memoria de los binarios, utilizando la ruta criptográfica del kernel en lugar de mecánicas de copia de archivos.

Para un atacante, eso tiene ventajas claras. El código del exploit se mantiene pequeño y sencillo, no depende de condiciones de carrera complejas y se apoya en APIs —AF_ALG y operaciones AEAD— que suelen estar activas por defecto porque muchas aplicaciones legítimas las usan para cifrado y autenticación.

Desde el punto de vista defensivo, Copy Fail refuerza una preocupación creciente: las optimizaciones de rendimiento en el kernel pueden introducir vulnerabilidades serias si no se someten a auditorías de seguridad profundas, algo nada trivial en un código tan extenso y cambiante como el de Linux.

El papel de la inteligencia artificial en el descubrimiento de Copy Fail

Otro aspecto llamativo de este caso es cómo se ha descubierto una vulnerabilidad que llevaba activa desde 2017 sin que nadie reparase en ella. Equipos como Xint Code y Theori han explicado que el hallazgo no se debe solo a revisiones manuales, sino al uso de herramientas de análisis de código asistidas por inteligencia artificial.

Estas soluciones realizan un escaneo masivo del código del kernel, buscando patrones de acceso a memoria potencialmente peligrosos y combinaciones de funciones que encajan con modelos de riesgo previamente entrenados. En subsistemas tan enrevesados como el criptográfico, donde se mezclan plantillas, macros y optimizaciones, un ojo humano puede pasar por alto interacciones sutiles.

La IA ayuda a destacar fragmentos de código donde conviene mirar con lupa. En el caso de Copy Fail, este enfoque permitió localizar el bug lógico en authencesn y su relación con la optimización de 2017 y el uso de splice(), algo que había escapado a auditorías previas.

Para organizaciones europeas que mantienen su propio software de bajo nivel o adaptan kernels, el mensaje es doble: incluso el código más auditado puede esconder fallos críticos durante años, y las herramientas de análisis automatizado basadas en IA empiezan a ser un aliado casi imprescindible para reforzar la seguridad.

Estado de los parches: kernels corregidos y respuesta de las distribuciones

La solución estructural pasa, como siempre en estos casos, por actualizar el kernel de Linux a una versión que incorpore el parche correspondiente para CVE-2026-31431. En el árbol oficial, el cambio clave corrige la gestión de buffers en algif_aead y revierte la optimización in-place problemática.

Las ramas estables del kernel han incorporado el arreglo en versiones como 6.18.22, 6.19.12 y 7.0, con backports en curso hacia versiones de soporte prolongado. A partir de ahí, cada distribución está integrando el parche en sus propios paquetes y kernels personalizados.

Distribuciones muy presentes en España y el resto de Europa, como Ubuntu, Debian, SUSE y RHEL, han ido publicando avisos de seguridad y nuevas versiones de kernel. En muchos casos, los trackers oficiales marcan los paquetes afectados como «fix released» o «fix pending», detallando en qué ramas se ha resuelto el problema.

Amazon Linux, ampliamente utilizado en infraestructuras alojadas en regiones europeas de AWS, ha ido actualizando también las ramas 5.4, 5.10, 5.15, 6.12 y 6.18, aunque los administradores deben verificar qué AMI y qué canal de actualizaciones están usando, porque no todas las imágenes se actualizan al mismo ritmo.

El punto delicado lo ponen las versiones fuera de soporte, como algunas instalaciones de Ubuntu 16.04 o 18.04 aún en producción en pequeñas empresas o proveedores regionales. En estos casos, la ausencia de parches oficiales implica que el riesgo de Copy Fail (y de otros CVE recientes) se mantiene indefinidamente mientras esos sistemas sigan en uso.

Medidas de mitigación temporal: qué hacer si no puedes actualizar ya

Aunque la recomendación general es clara —parchear y reiniciar los kernels cuanto antes—, en la práctica no siempre es posible detener de golpe servicios que dan soporte a hospitales, bancos o administraciones públicas. Por eso, los investigadores han descrito varias medidas de mitigación temporal que ayudan a reducir la superficie de ataque.

Una de las primeras acciones sugeridas consiste en deshabilitar el módulo algif_aead mediante la configuración de modprobe. Añadiendo reglas de blacklist se evita que el módulo se cargue de nuevo tras un reinicio, y es posible descargarlo en caliente con rmmod si no hay dependencias críticas.

En entornos de alto riesgo o donde se ejecuta mucho código no confiable, algunos equipos de seguridad recomiendan un paso más drástico: restringir por completo el uso de AF_ALG mediante políticas de seguridad como seccomp, AppArmor o SELinux. Con ello se cierra el vector de ataque principal de Copy Fail, aunque hay que valorar el impacto sobre aplicaciones legítimas que usen el subsistema criptográfico del kernel.

Otra medida complementaria pasa por revisar el número de binarios con bit setuid presentes en los sistemas y eliminar o sustituir aquellos que no sean estrictamente necesarios. Reducir la cantidad de objetivos potenciales no evita el bug, pero dificulta el trabajo al atacante y puede limitar el alcance de una explotación exitosa.

En determinadas distribuciones, como Ubuntu, se están utilizando utilidades de comprobación y asistentes de mitigación que permiten identificar si el kernel de la máquina sigue siendo vulnerable a CVE-2026-31431 y aplicar medidas provisionales. En cualquier caso, estas herramientas deben verse solo como un apoyo: el objetivo final sigue siendo migrar a kernels corregidos.

Detección y monitorización: cómo cazar intentos de explotación de Copy Fail

Más allá de aplicar parches, muchas organizaciones quieren saber si alguien ha intentado aprovechar Copy Fail en sus sistemas o, al menos, montar mecanismos de alerta temprana. Dado que el ataque deja pocas señales en disco, la detección se centra sobre todo en patrones de comportamiento a nivel de sistema.

Un enfoque habitual consiste en configurar reglas de auditd para vigilar el uso de splice() y AF_ALG por parte de usuarios no privilegiados. Por ejemplo, registrar llamadas a splice que manipulen descriptores de archivos asociados a binarios con setuid (como su, sudo, passwd, gpasswd, mount, umount o fusermount3) cuando se originan desde intérpretes como Python en ubicaciones poco habituales.

También se recomienda monitorizar la creación de sockets AF_ALG (familia 26 en decimal) desde UIDs de usuario interactivo, especialmente en servidores donde no se espera un uso intensivo de la API criptográfica del kernel por parte de aplicaciones estándar.

Fabricantes de soluciones EDR y plataformas SIEM han empezado a publicar reglas específicas para Copy Fail, con nombres del estilo possible_copy_fail_cve_2026_31431 o possible_lpe_by_python. Estas reglas suelen correlacionar varios eventos: lectura de binarios setuid, uso de splice, creación de sockets AF_ALG y lanzamiento posterior de una shell con privilegios elevados.

En organizaciones con infraestructuras complejas en España y otros países de la UE —banca, energía, sector público— integrar estos indicadores de compromiso en sus sistemas de monitorización centralizados es clave. No garantiza descubrir todos los intentos, pero eleva de forma notable las probabilidades de detectar explotación en curso o pruebas internas no autorizadas.

Recomendaciones prácticas para empresas y administradores en Europa

Para cualquier organización que dependa de Linux en producción, desde pequeñas pymes hasta grandes proveedores cloud, Copy Fail obliga a combinar acciones inmediatas con una revisión más estratégica de la postura de seguridad.

A corto plazo, es razonable seguir una hoja de ruta basada en unos cuantos pasos claros: inventariar sistemas, revisar kernels y priorizar entornos expuestos. Ejecutar uname -r en todos los servidores, contrastar la versión con los avisos oficiales de Ubuntu, Debian, RHEL, SUSE o Amazon Linux y aplicar los parches publicados es el primer movimiento obligado.

La prioridad debe ir para servidores accesibles desde Internet, plataformas multiusuario y nodos de Kubernetes o runners de CI/CD que ejecuten código de terceros. Allí donde no se pueda reiniciar de inmediato, las mitigaciones temporales —deshabilitar algif_aead, restringir AF_ALG, reducir binarios setuid— ayudan a comprar tiempo sin dejar el sistema completamente expuesto.

A medio plazo, merece la pena revisar cuántos kernels sin soporte o sin actualizaciones regulares siguen en producción y planificar migraciones. Mantener versiones obsoletas por miedo a “romper producción” es una deuda técnica que, como demuestra CVE-2026-31431, se paga tarde o temprano en forma de brechas.

Finalmente, integrar de forma más sistemática herramientas de análisis automatizado e inteligencia artificial en los procesos de desarrollo y pruebas internas puede ayudar a detectar fallos lógicos similares antes de que lleguen a producción. Combinado con una monitorización más afinada de AF_ALG y de patrones de explotación, este enfoque permite que incidentes como Copy Fail sean algo menos traumáticos la próxima vez que aparezca un bug en el corazón del kernel.

Todo lo ocurrido con Copy Fail (CVE-2026-31431) deja claro que incluso un pequeño error lógico en el subsistema criptográfico de Linux puede poner en jaque a servidores compartidos, clústeres de contenedores y servicios críticos en cuestión de segundos. Actualizar los kernels, desactivar módulos vulnerables donde no sean necesarios y reforzar monitorización y procesos de parcheo se ha convertido, para muchas organizaciones españolas y europeas, en una tarea tan urgente como inaplazable.