La comunidad de seguridad lleva días con la mirada puesta en Copy Fail, la vulnerabilidad CVE-2026-31431 que afecta al kernel de Linux y permite que un usuario local sin privilegios llegue a ser root en cuestión de segundos. El fallo, que ha permanecido camuflado desde 2017, ha encendido todas las alarmas en empresas, proveedores cloud y administraciones públicas europeas que dependen de Linux para casi todo.
Lo que más preocupa a los equipos de ciberseguridad no es solo el impacto técnico, sino la combinación de factores: un exploit diminuto, un fallo lógico muy fiable y una detección especialmente complicada. En entornos donde se ejecuta código de terceros a diario —desde servidores compartidos en España hasta clústeres de Kubernetes en grandes nubes europeas— Copy Fail se ha convertido, de la noche a la mañana, en una prioridad absoluta.
Qué es Copy Fail (CVE-2026-31431) y cómo se descubrió
Copy Fail es una vulnerabilidad de escalada local de privilegios (LPE) en el kernel de Linux, rastreada como CVE-2026-31431. Permite que cualquier usuario con capacidad de ejecutar código en la máquina —una cuenta normal, un proceso dentro de un contenedor Docker o un job de CI— pueda elevar sus permisos hasta root en sistemas vulnerables.
El fallo fue publicado a finales de abril de 2026 por equipos de investigación como Xint Code y Theori, que identificaron un proof-of-concept en Python de apenas 732 bytes capaz de explotar un error lógico en el subsistema criptográfico. Ese pequeño script, con unas pocas líneas, se apoya en sockets AF_ALG y la llamada splice() para corromper la caché de página de binarios sensibles y disparar la escalada de privilegios.
Según los análisis técnicos, el problema llevaba escondido desde 2017 en kernels distribuidos por prácticamente todas las grandes familias de Linux. Durante casi nueve años, el bug pasó inadvertido a pesar de auditorías y revisiones de código continuas, lo que ha despertado un debate profundo sobre cómo se revisan optimizaciones de rendimiento en componentes tan delicados como la criptografía del kernel.
Un detalle especialmente llamativo es el papel de la inteligencia artificial: herramientas de análisis automático de código, como Xint Code, han sido clave para localizar la vulnerabilidad detectando patrones de comportamiento anómalos en el módulo afectado. Sin estas soluciones, muchos expertos admiten que habría sido muy difícil encontrar el fallo a mano.
La raíz del problema: el módulo criptográfico algif_aead
En el centro de Copy Fail está el subsistema criptográfico del kernel de Linux, y más en concreto la interfaz algif_aead accesible desde espacio de usuario a través de sockets AF_ALG. Esta interfaz permite que aplicaciones sin privilegios especiales utilicen funciones criptográficas del kernel para operaciones de cifrado y autenticación AEAD.
El bug se origina en una optimización introducida en 2017 —referenciada en varios análisis como un commit de mejora “in-place” en algif_aead— que rompió inadvertidamente las garantías de seguridad del módulo. El cambio pretendía ganar rendimiento reutilizando buffers de entrada y salida, pero abrió la puerta a una escritura fuera de límites dentro de la caché de página.
La vulnerabilidad se manifiesta en la plantilla criptográfica authencesn, que combina HMAC-SHA256 con AES-CBC. Durante ciertas operaciones AEAD, parte de la memoria destinada a salida se usa como zona de trabajo temporal, y debido al bug se escriben 4 bytes justo fuera del área esperada, sobre una página de la caché de archivos del sistema.
Esa minúscula corrupción controlada, de solo cuatro bytes, resulta ser suficiente para manipular en memoria binarios con bit setuid como /usr/bin/su, sudo o utilidades similares. El archivo en disco no se toca, pero la copia en la caché de páginas sí, y es justo esa copia la que el kernel ejecuta cuando se lanza el programa.
Copia en memoria, disco intacto: por qué es tan difícil de detectar
Una de las características que hacen especialmente delicada esta vulnerabilidad es que solo altera la versión en memoria de los archivos. Linux utiliza la caché de páginas para acelerar el acceso a ficheros: en lugar de leer siempre desde el disco, mantiene copias en RAM para responder más rápido.
Copy Fail aprovecha esta mecánica para modificar, a través del error en algif_aead, 4 bytes concretos de la página de caché de un binario elegido por el atacante. La clave está en que el kernel no marca esa página como «sucia», así que nunca escribe los cambios de vuelta al disco. Desde el punto de vista del sistema de archivos, todo sigue impecable.
Esto tiene varias consecuencias prácticas: por un lado, las comprobaciones de integridad basadas en hashes de archivo no detectan nada raro, porque el contenido físico en disco no cambia. Por otro, el rastro del ataque es volátil: un reinicio o cierta presión de memoria que fuerce recargar el fichero desde disco elimina toda huella de la corrupción anterior.
Además, el exploit emplea llamadas al sistema perfectamente legítimas (socket con AF_ALG, splice, execve de /usr/bin/su, etc.), de modo que su comportamiento se mimetiza con el tráfico normal del kernel. Incluso soluciones EDR avanzadas pueden tener dificultades para distinguir un uso legítimo de AF_ALG de un intento de explotación, salvo que se apliquen reglas muy específicas.
Cómo se explota Copy Fail: AF_ALG, splice y un script diminuto
Los investigadores han demostrado que basta con un script en Python de unos 732 bytes para explotar la vulnerabilidad en condiciones reales. El proceso, resumido, sigue una secuencia relativamente sencilla pero muy efectiva.
En primer lugar, el exploit abre un socket AF_ALG configurado en modo AEAD apuntando a la plantilla authencesn vulnerable. Después, se prepara un descriptor asociado a la caché de páginas de un binario setuid objetivo, por ejemplo /usr/bin/su, y se utiliza la llamada splice() para conectar esa página de caché con el buffer que el kernel usará como destino de la operación criptográfica.
Durante la operación de cifrado/autenticación, debido al bug introducido en 2017, el código del kernel realiza una escritura de 4 bytes fuera del rango previsto del buffer. El atacante controla tanto los datos de entrada como los parámetros de la petición, por lo que puede decidir qué valor se escribe y en qué offset dentro de la página de caché.
Repitiendo este patrón las veces necesarias, el exploit puede ir ajustando instrucciones críticas del binario en memoria (por ejemplo, cambiando una rutina de comprobación de contraseñas por una secuencia que lance un shell privilegiado). Cuando el atacante ejecuta el binario modificado, el kernel tira de la copia en caché y no del disco, por lo que se obtiene un shell real de root.
Un punto importante a tener en cuenta es que Copy Fail no abre por sí solo una puerta desde internet. Siempre hace falta algún vector previo que permita ejecutar código local: una vulnerabilidad en una web, una cuenta comprometida, un contenedor con permisos limitados, un script de CI mal protegido, etc. Pero una vez se supera ese primer paso, la escalada a root con Copy Fail es, según los investigadores, muy fiable en entornos convencionales.
Sistemas y distribuciones afectadas: impacto en Europa y entornos empresariales
Los análisis publicados hasta la fecha coinciden en que la práctica totalidad de kernels Linux distribuidos desde 2017 que incluyen algif_aead y AF_ALG habilitado se ven afectados por la vulnerabilidad. Eso abarca la mayoría de distribuciones utilizadas en España y el resto de Europa, tanto en servidores como en estaciones de trabajo y entornos cloud.
Entre los sistemas señalados se encuentran Ubuntu, Debian, SUSE, Red Hat Enterprise Linux (RHEL), Amazon Linux y diversas compilaciones empleadas en WSL2. Las ramas LTS de Ubuntu (16.04, 18.04, 20.04, 22.04 y superiores) han recibido o están recibiendo actualizaciones, aunque algunas versiones fuera de soporte —como ciertos kernels de 18.04— ya no tendrán parche oficial y quedan en una situación de riesgo permanente.
En el caso de Debian, los trackers de seguridad indican que versiones de bullseye, bookworm y trixie con kernels 5.x y 6.x concretos están o han estado afectadas. Amazon Linux 2 y Amazon Linux 2023, ampliamente usados en instancias EC2 y nodos EKS, figuran también como vulnerables con parches pendientes o recién liberados en diversas ramas (5.4, 5.10, 5.15, 6.12, 6.18).
Para las organizaciones europeas que alojan infraestructuras críticas —operadoras, banca, sector público o grandes proveedores de hosting— esto supone que miles de servidores han necesitado revisiones urgentes de kernel. No basta con mirar el número de versión genérico: muchas distribuciones aplican backports y parches propios, por lo que es imprescindible revisar los avisos de seguridad oficiales de cada proveedor.
La vulnerabilidad ha sido clasificada en torno a 7,8 sobre 10 en la escala CVSS, dentro de la categoría de «Alta gravedad». Aunque no es un 0-day remoto que permita tomar control de un sistema desde fuera sin más, su capacidad para convertir un acceso local limitado en control absoluto hace que, en la práctica, sea un riesgo muy serio para infraestructuras modernas.
Por qué Copy Fail es tan peligrosa en cloud, contenedores y CI/CD
En un ordenador doméstico con un solo usuario, el riesgo de Copy Fail puede parecer, a primera vista, manejable. El problema real aparece en arquitecturas multi-tenant y entornos donde se ejecuta código de terceros de forma habitual, algo muy común en empresas españolas y europeas que han migrado masivamente a la nube.
En clústeres de Kubernetes, por ejemplo, un atacante que consiga ejecutar código dentro de un pod con pocos permisos podría usar Copy Fail para romper el aislamiento del contenedor y escalar al nodo host si el kernel subyacente no está parcheado. Desde ahí, el paso a comprometer otros pods o incluso el clúster completo es solo cuestión de encadenar movimientos.
Lo mismo ocurre en runners de CI/CD (GitHub Actions, GitLab, Jenkins, sistemas internos) que compilan código de múltiples proyectos o ejecutan tests de terceros. Un fallo en una pipeline o un repositorio malicioso podrían ser el punto de entrada para lanzar el exploit y tomar control del host que ejecuta los jobs.
En proveedores de VPS y hosting compartido, muy extendidos en el mercado español y europeo, un cliente con acceso a una máquina aparentemente aislada podría usar Copy Fail para saltar al sistema físico que aloja varias máquinas virtuales o contenedores, rompiendo así la separación entre clientes.
Todo esto explica por qué la vulnerabilidad ha generado tanta presión entre proveedores cloud, centros de datos y equipos de operaciones: no se trata solo de proteger una máquina concreta, sino de preservar los límites de aislamiento que sostienen modelos de negocio completos.
Estado de los parches y respuesta de las distribuciones
La solución estructural pasa por actualizar el kernel a una versión que incluya el parche de Copy Fail. En el árbol oficial de Linux, el cambio clave revierte la optimización problemática de algif_aead y endurece la gestión de buffers en las operaciones criptográficas afectadas.
Las principales distribuciones han reaccionado con distinta velocidad. Debian, Ubuntu y SUSE lanzaron actualizaciones de seguridad con bastante rapidez, cubriendo tanto ramas estables como LTS. Algunos paquetes muy específicos —como ciertos kernels optimizados para IBM en Ubuntu— se han marcado como «no afectados» al no incluir el código vulnerable.
En el caso de Red Hat, la reacción inicial fue algo más cauta, con un planteamiento de evaluar el impacto antes de liberar parches en todas las ramas. Sin embargo, ante la presión de la comunidad y las pruebas de concepto públicas, la compañía acabó acelerando la publicación de actualizaciones para sus productos empresariales, conscientes de la importancia que tiene RHEL en el tejido corporativo europeo.
Amazon Linux, por su parte, ha ido actualizando progresivamente sus kernels para instancias EC2 y nodos de EKS. Aun así, muchos administradores en España y otros países europeos han tenido que revisar manualmente qué AMI y qué rama de kernel estaba utilizando cada servidor, ya que no todas las imágenes reciben actualizaciones al mismo ritmo.
En entornos donde se mantienen versiones antiguas fuera de soporte, como algunas instalaciones de Ubuntu 16.04 o 18.04 aún presentes en pequeños proveedores o infraestructuras heredadas, la situación es más delicada: esos sistemas, en muchos casos, no recibirán parche, por lo que seguir utilizándolos expone de forma permanente a Copy Fail y a otras vulnerabilidades recientes.
Medidas de mitigación temporal: qué hacer si no puedes actualizar ya
Aunque la recomendación general es clara —parchear y reiniciar el kernel lo antes posible—, en la práctica no todas las organizaciones pueden detener servicios críticos de golpe. Para estos casos, los investigadores han descrito varias estrategias de mitigación temporal que reducen significativamente la superficie de ataque.
La primera consiste en poner en lista negra el módulo algif_aead mediante modprobe. Añadiendo reglas adecuadas, se impide que el módulo se cargue automáticamente y se puede incluso descargar del kernel en ejecución con comandos como rmmod, siempre que no existan dependencias activas que lo impidan.
Otra opción más contundente, recomendada para cargas de trabajo no confiables o entornos de alto riesgo, es bloquear la creación de sockets AF_ALG mediante políticas seccomp o sistemas de control de acceso como AppArmor o SELinux. Esta medida cierra la vía principal de explotación de Copy Fail, pero puede afectar a aplicaciones legítimas que dependan del subsistema criptográfico del kernel.
Algunos proveedores y equipos de seguridad también sugieren revisar y reducir el número de binarios con bit setuid presentes en los sistemas. Aunque no elimina la vulnerabilidad, bajar la cantidad de objetivos potenciales dificulta la tarea al atacante y limita el impacto de una explotación exitosa.
En entornos Ubuntu, se han publicado ejemplos de uso de utilidades como profix para comprobar el estado del CVE en cada sistema y facilitar al administrador la aplicación de mitigaciones provisionales. Eso sí, estas soluciones deben entenderse como parches temporales: el objetivo final sigue siendo actualizar a un kernel corregido.
Cómo detectar intentos de explotación: auditoría, SIEM y EDR
Más allá de parchear, muchas organizaciones quieren saber si alguien ha intentado o ha llegado a explotar Copy Fail en sus sistemas. Dado que el ataque deja pocas huellas evidentes en disco, la detección se basa sobre todo en monitorizar patrones de comportamiento sospechosos a nivel de sistema.
Una de las recomendaciones recurrentes es configurar reglas de auditd para vigilar el uso de splice() y AF_ALG por parte de usuarios no privilegiados. Por ejemplo, registrar llamadas splice que manipulen descriptores de archivos asociados a binarios setuid como su, sudo, passwd, gpasswd, newgrp, chfn, chsh, mount o fusermount3, cuando se originan desde intérpretes como Python en rutas atípicas.
También se aconseja monitorizar la creación de sockets con el dominio AF_ALG (valor 26 en decimal) iniciados por UIDs de usuario interactivo (normalmente mayores o iguales a 1000) en sistemas donde no se espera un uso intensivo de la API criptográfica del kernel desde aplicaciones de usuario estándar.
Soluciones EDR y plataformas SIEM están empezando a incorporar reglas específicas para Copy Fail, con nombres como possible_lpe_by_python o possible_copy_fail_cve_2026_31431. 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.
Para organizaciones con infraestructuras complejas —banca, energía, sector público—, integrar estos indicadores de compromiso en sus sistemas de monitorización centralizados es clave. Aunque no garantiza detectar todos los intentos, eleva significativamente las probabilidades de identificar explotación en curso o pruebas internas no autorizadas.
Lecciones frente a otras vulnerabilidades del kernel: Dirty COW, Dirty Pipe y compañía
Copy Fail no es la primera vulnerabilidad de escalada de privilegios que sacude el kernel de Linux. En la última década se han hecho célebres fallos como Dirty COW (CVE-2016-5195) o Dirty Pipe (CVE-2022-0847), que también jugaban con la caché de páginas y mecanismos internos del kernel para modificar datos que, en teoría, eran de solo lectura.
La diferencia es que, mientras Dirty COW y Dirty Pipe se centraban más en escritura arbitraria en archivos en disco o en tuberías, Copy Fail actúa casi exclusivamente sobre la copia en memoria, sin alterar el contenido físico. Para un atacante, esto se traduce en una ventaja enorme en términos de sigilo, ya que las herramientas clásicas de análisis forense se basan en gran medida en el estado del sistema de archivos.
Otro aspecto interesante es que CVE-2026-31431 encaja en un patrón que muchos expertos llevan tiempo señalando: optimizar el rendimiento del kernel sin evaluar a fondo las implicaciones de seguridad puede generar vulnerabilidades muy serias. Un cambio pensado para ahorrar ciclos de CPU en operaciones criptográficas ha acabado exponiendo a millones de servidores.
Para las empresas europeas que operan su propia infraestructura o dependen de proveedores cloud, la lección es clara: no se puede tratar el mantenimiento del kernel como una tarea secundaria. Retrasar actualizaciones por miedo a “romper producción” acumula una deuda técnica que termina pasando factura en forma de brechas de seguridad cada vez más complejas.
Esta vez, además, el papel de la inteligencia artificial en el descubrimiento de Copy Fail deja entrever otro futuro posible: las mismas técnicas avanzadas que hoy ayudan a localizar bugs podrían emplearse para encontrarlos antes que los defensores. Mantener una cultura de parcheo ágil y de monitorización continua se vuelve, por tanto, todavía más imprescindible.
Todo lo ocurrido con Copy Fail (CVE-2026-31431) refuerza una idea que muchas organizaciones europeas ya están asimilando a marchas forzadas: un único fallo lógico en el corazón del kernel puede comprometer contenedores, servidores compartidos y servicios críticos en cuestión de segundos. Actualizar los kernels, desactivar módulos vulnerables donde no sean necesarios, reforzar la monitorización de AF_ALG y revisar los entornos multi-tenant y de CI/CD se ha convertido en una tarea urgente para cualquier equipo que administre sistemas Linux, desde pequeñas empresas hasta grandes proveedores cloud.