Lo he escrito en más de una ocasión: el próximo ataque masivo no empezará con el estruendo de un misil, sino con una instrucción de cuatro bytes que se cuela en silencio en la memoria de un servidor. La semana pasada lo volví a recordar cuando el equipo de Xint Code publico los detalles de ‘Copy Fail’, un fallo lógico en el kernel de Linux que la agencia de ciberseguridad estadounidense, CISA, acaba de añadir a su catálogo de vulnerabilidades explotadas activamente (KEV). La vulnerabilidad, registrada como CVE-2026-31431 y con una puntuación CVSS de 7,8, permite a un usuario local, sin privilegio alguno, escribir cuatro bytes controlados en el page cache de cualquier fichero legible y escalar directamente a root. Sin modificar nada en disco. Sin dejar rastro en el sistema de ficheros.
No es un bug más. Es un implante lógico, determinista y reproducible en un script de apenas 732 bytes. Cualquier ordenador con un kernel compilado entre 2017 y la semana pasada —y eso cubre prácticamente todas las distribuciones Linux de escritorio y servidor— está en el punto de mira. Ubuntu, Red Hat, SUSE, Amazon Linux… todas las grandes han confirmado ya la vulnerabilidad. Y CISA, al incluirla en el KEV, certifica lo que los investigadores de Xint Code ya advirtieron: Copy Fail está siendo explotado por actores hostiles en entornos reales, y no es una prueba de concepto de laboratorio.
El fallo combina dos subsistemas del kernel que ningún administrador desactiva: AF_ALG, la interfaz de usuario para el subsistema criptográfico, y splice(), la llamada al sistema que mueve páginas de memoria entre tuberías y ficheros sin copiarlas. La trampa se monta así: un atacante sin privilegios abre un socket AF_ALG, lo vincula al modo AEAD del algoritmo authencesn y utiliza splice() para mapear páginas del page cache de un fichero legible —por ejemplo, /usr/bin/su, un binario con el bit setuid activado— directamente en la lista de dispersión (scatterlist) de la operación criptográfica. A continuación, inicia un descifrado y fuerza a que el kernel escriba cuatro bytes de relleno —un desbordamiento calculado— sobre la página del fichero en memoria. El disco permanece intacto, pero la copia en el page cache queda corrompida con el valor elegido por el atacante.
El proceso se repite hasta inyectar una shellcode completa dentro del binario en memoria. Cuando el atacante ejecuta /usr/bin/su, el kernel carga la versión modificada desde el page cache y la ejecuta con privilegios de root. Todo ello sin alterar el fichero en disco, sin ficheros temporales, sin depurador y sin carreras (race conditions) que delaten el ataque. La demo de los investigadores muestra el mismo script de 732 bytes corriendo en Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 y SUSE 16, y un usuario con uid 1001 obteniendo root en los cuatro sistemas. El exploit no requiere conexión de red, ni módulos del kernel, ni primitivas preinstaladas. Cualquier usuario local con acceso a una shell puede ejecutarlo.
Anatomía técnica: cómo Copy Fail concede root en cuatro bytes
La clave del ataque está en el comportamiento del algoritmo authencesn, una plantilla criptográfica del kernel pensada para cifrado autenticado con datos adicionales (AEAD). Durante el descifrado, el kernel marca la operación como in-place —es decir, la salida se escribe en el mismo buffer de entrada— y, aquí viene la trampa, authencesn usa el buffer de salida como espacio de trabajo temporal y escribe cuatro bytes más allá del límite permitido. Si ese buffer es una página del page cache —gracias a la combinación con splice()—, los cuatro bytes van a parar directamente a la memoria del fichero legible. El atacante controla qué fichero, qué desplazamiento dentro de la página y qué cuatro bytes escribe. Es, en términos del oficio, una corrupción de memoria precisa, portable y sin ruido.
Los investigadores de Xint Code recurrieron a análisis asistido por inteligencia artificial para rastrear la anomalía en el subsistema criptográfico. La interacción defectuosa entre AF_ALG, splice() y la optimización in-place introducida en 2017 permaneció oculta durante más de ocho años. La lógica del bug es sutil: el page cache corrupto nunca se marca como “sucio” (dirty), así que las operaciones de sincronización de disco no lo sobrescriben. Hasta que el binario modificado se expulsa de la caché y se vuelve a cargar desde disco –algo que puede tardar horas o no ocurrir nunca si el sistema está bajo carga–, la versión envenenada sigue ejecutándose.
La elegancia técnica de ‘Copy Fail’ no está en lo que escribe, sino en lo que no escribe: no toca el disco, no altera el fichero, y mientras tanto, cualquier proceso que lea esa página de memoria está viendo una versión modificada que le concede root.
De Dirty COW a Copy Fail: la evolución del oficio en el kernel
Copy Fail no es el primer bug de escalada de privilegios basado en el page cache, pero sí el más quirúrgico. En 2016, Dirty COW (CVE-2016-5195) permitía escribir en páginas de sólo lectura mediante una condición de carrera en la gestión de COW (copy-on-write). Era ruidoso, requería múltiples intentos y, a menudo, se detectaba por el alto consumo de CPU. En 2022, Dirty Pipe (CVE-2022-0847) explotó una mala sincronización en pipe buffers para obtener escritura en páginas del disco, pero afectaba a kernels posteriores a 5.8. Copy Fail es distinto: no depende de condiciones de carrera, funciona en todas las arquitecturas y en prácticamente cualquier kernel moderno desde 2017 hasta hace unos días.
Lo que hace especialmente peligroso a este fallo es su sigilo. No modifica el fichero en disco, por lo que las comprobaciones de integridad basadas en hashes del sistema de ficheros (como IMA/EVM) no lo detectan. Tampoco deja eventos de escritura a nivel de VFS. El único rastro mínimo estaría en los registros de auditoría de llamadas al sistema —si están activados y se monitoriza AF_ALG—, pero eso no es habitual en la mayoría de los servidores de producción. Me consta, además, que el CNI y el CCN-CERT hace años que vigilan de cerca las técnicas de escalada local en sistemas Linux; de hecho, en El quinto elemento ya advertí que “en España hay 8.000 infraestructuras críticas y atacables a través de internet”, muchas de ellas corriendo sobre Linux.
Dossier Moncloa: Ojos en la Sombra
El vector de amenaza es claro: escalada de privilegios local (LPE) mediante explotación de un bug lógico en el kernel Linux. La explotación activa confirmada por CISA eleva el riesgo de inmediato. Aunque la atribución final de los atacantes que están aprovechando Copy Fail está por determinar, la inclusión en el catálogo KEV sigue los criterios de la Directiva Operativa Vinculante 22-01, que exige que haya evidencias de explotación por parte de actores hostiles, no meras pruebas de concepto. Eso apunta, en la práctica, a grupos APT o a actores criminales sofisticados que ya han integrado el exploit en sus cadenas de ataque. No sería la primera vez que una vulnerabilidad del kernel se utiliza para comprometer infraestructuras en España; recuerdo el caso de la red de espionaje rusa desarticulada en 2022, donde los atacantes emplearon un bug similar en el kernel para pivotar desde un servidor web comprometido hacia el resto de la red corporativa.
Las agencias implicadas se dividen en tres frentes. El servicio atacante es, por el momento, desconocido —la atribución técnica no ha arrojado un nombre—, pero el perfil del exploit (silencioso, portable, capaz de cruzar contenedores) encaja con las necesidades de cualquier servicio de inteligencia que quiera extraer información de entornos virtualizados o saltar entre pods de Kubernetes. La defensa recae, en primera instancia, en los administradores de sistemas y en los fabricantes de distribuciones, pero la responsabilidad última de alertar y coordinar en España corresponde al CCN-CERT y al CNI. La agencia estadounidense CISA actúa como catalizador y fuente de autoridad, y su decisión de fijar el plazo del 15 de mayo para las agencias federales es una señal de urgencia que el resto del mundo haría bien en copiar. En tercer lugar, los observadores —desde el MI5 británico hasta el BND alemán— están analizando la misma información y actualizando sus propias matrices de riesgo.
El material involucrado en este fallo no es clasificado en sí mismo; los detalles técnicos han sido publicados por los investigadores de Xint Code y están disponibles en abierto. Sin embargo, el hecho de que CISA confirme la explotación activa sin revelar quién la está llevando a cabo indica que, muy probablemente, la inteligencia de señales (SIGINT) de Estados Unidos haya interceptado comunicaciones o detectado tráfico de mando y control que utiliza este exploit, y esa información sí podría estar clasificada. Por mi experiencia, estimo que el nivel de la inteligencia asociada a la explotación en curso es Secreto, al menos en lo que respecta a la identidad del adversario.
El precedente histórico más inmediato es Dirty COW, pero también conviene recordar el caso de Stuxnet (2010), donde una vulnerabilidad del kernel de Windows se combinó con drivers firmados robados para sabotear centrifugadoras en Natanz. Aquello era un arma cibernética de precisión; Copy Fail, por su parte, es una herramienta versátil que cualquier grupo puede incorporar a su arsenal. La diferencia está en que en 2010 las atribuciones tardaron meses en asentarse; hoy, la comunidad de ciberseguridad dispone de capacidades de análisis asistido por IA que aceleran la detección y la publicación. Precisamente, fue la IA la que ayudó a Xint Code a encontrar el fallo. Esto abre un nuevo capítulo en la caza de vulnerabilidades: la IA no solo automatiza el descubrimiento de bugs, sino que obliga a los servicios de inteligencia a revisar sus propias capacidades ofensivas, porque lo que un laboratorio de investigación puede desvelar en semanas, un servicio hostil podría haberlo estado utilizando en silencio durante años.
El cierre práctico para usted, lector, es inmediato. Parchee sin demora. CISA exige a las agencias federales estadounidenses que corrijan la vulnerabilidad antes del 15 de mayo de 2026. En España, el CCN-CERT ya ha emitido una actualización de su índice de severidad para sistemas gubernamentales, y se espera que en las próximas horas publique una nota técnica específica para infraestructuras criticas, sobre todo para aquellas que operan con Kubernetes o con entornos de contenedores. Mi opinión es que cualquier retraso en la aplicación del parche, por mínimo que sea, es una invitación a un adversario que ya tiene el exploit, el método y la voluntad.
