Los fundamentos de la seguridad de Linux acaban de tener un mal día. Lo cuenta The Verge este 30 de abril a partir de la divulgación de Theori, la firma de seguridad coreana que descubrió el bug. CVE-2026-31431, conocida cómo «Copy Fail», es una vulnerabilidad en el módulo criptográfico authencesn del kernel de Linux que permite a cualquier usuario local sin privilegios obtener acceso root en prácticamente todas las distribuciones de Linux desde 2017. La explotación es trivial: un script de Python de 732 bytes (10 líneas) usando solo módulos de la biblioteca estándar, ningún payload compilado, ninguna instalación de dependencias.
La frase del writeup de Theori captura el problema: «un usuario local sin privilegios puede escribir cuatro bytes controlados en la page cache de cualquier archivo legible en un sistema Linux, y usarlo para obtener root». El kernel lee la page cache cuando carga un binario, así que modificar la copia cacheada equivale a alterar el binario para fines de ejecución. Y, lo más insidioso, esa modificación no dispara ninguna defensa basada en eventos de sistema de archivos cómo inotify. La vulnerabilidad ha estado silenciosamente explotable durante casi una década y nadie la había detectado.
Cómo funciona Copy Fail técnicamente
Copy Fail es un bug de lógica directa, no una race condition. Eso lo distingue de vulnerabilidades anteriores famosas cómo Dirty Cow (CVE-2016-5195), que requería ganar una race en el VM subsystem y a menudo necesitaba múltiples intentos, o Dirty Pipe (CVE-2022-0847), que era específica de versión y exigía manipulación precisa del pipe buffer. Copy Fail dispara fiable, sin races, sin retries, sin ventanas de timing propensas a crashes. El mismo script funciona sin modificación en Ubuntu, Amazon Linux, RHEL y SUSE.
El bug nació en 2017, cuando se añadió a algif_aead.c (commit 72548b093ee3) una optimización que permitía operaciones AEAD in-place. Para descifrado, el código copiaba datos AAD y ciphertext desde la TX SGL al RX buffer, encadenando las páginas de tag por referencia. Eso convirtió las páginas de page cache (originalmente solo lectura) en partes del scatterlist de destino, escribible. La escritura de scratch del módulo authencesn al final del buffer caminaba directamente sobre esas páginas de page cache encadenadas, creando el bug. Cada cambio era razonable en aislamiento. La vulnerabilidad existe en la intersección de tres decisiones de diseño que nadie conectó.
El patrón de vulnerabilidades antiguas de Linux que pasan años escondidas no es nuevo. PwnKit, divulgada en enero de 2022, era una vulnerabilidad en el componente pkexec de Polkit presente desde hace 12 años en la configuración predeterminada de todas las principales distribuciones. Permitía obtener privilegios de root completos. Tras su publicación, apareció un exploit funcional en la web en solo tres horas. La diferencia con Copy Fail es la portabilidad universal: PwnKit afectaba a Linux, pero el script de Copy Fail funciona idéntico en cuatro distribuciones empresariales sin recompilación.
Los números: 732 bytes, 4 distros, 9 años
La estadística de Copy Fail es la que define la severidad. El exploit es un script de Python de 732 bytes usando solo os, socket y zlib. Requiere Python 3.10 o superior por os.splice. No hay payloads compilados ni offsets específicos por kernel. Funciona en Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 y SUSE 16, todas testeadas con el mismo script sin modificar. La CVE está rateada High severity, 7.8 sobre 10.
Más preocupante que la severidad técnica es el alcance. Cualquier sistema Linux con kernel desde 4.14 (lanzado en julio de 2017) hasta versiones actuales es vulnerable, salvo que tenga el parche aplicado. Eso incluye servidores corporativos, estaciones de trabajo, contenedores, runners de CI/CD y nodos de Kubernetes. Particularmente preocupante: la page cache es compartida entre procesos en un host, incluso entre fronteras de contenedores. Esto hace que Copy Fail sea un primitive de container escape: un contenedor comprometido puede corromper binarios setuid visibles a otros contenedores y al kernel del host. Theori promete una segunda parte de la investigación cubriendo compromiso completo de nodos Kubernetes.
Cómo se descubrió: IA buscando bugs
El detalle más inquietante para los defensores es cómo se encontró Copy Fail. El investigador Taeyang Lee de Theori usó el software propietario de la compañía, Xint Code, una herramienta de auditoría de código asistida por IA. Según el writeup de Theori, el sistema de IA «descubrió» la vulnerabilidad en aproximadamente una hora.
Bugcrowd ha analizado el dato y la consecuencia es seria. Vulnerabilidades de esta categoría (universales, sin race window, sin offsets por kernel, primitives de container escape) tradicionalmente se vendían en mercados grises a precios que el broker Crowdfense paga entre 10.000 y 7 millones de dólares. Zerodium llegó a pagar hasta 500.000 dólares por zero-days Linux de alta calidad antes de cerrar a principios de 2025. Que una herramienta IA haya producido este nivel de bug en una hora cambia la economía. Si el coste de descubrir bugs de kernel-grade ha caído un orden de magnitud, los presupuestos de seguridad construidos sobre la suposición de que estos bugs son raros (porque encontrarlos es caro) están desactualizados.
Ubuntu Pro y soluciones similares de soporte extendido se vuelven más relevantes en este contexto. Canonical extiende la cobertura de seguridad de cinco a diez años en versiones LTS y añade soporte técnico opcional para 23.000 paquetes adicionales. La cobertura desde Ubuntu 16.04 LTS en adelante es lo que hace que un parche urgente de seguridad cómo el de Copy Fail llegue rápido a sistemas en producción que de otro modo habrían quedado huérfanos.
Los parches y la mitigación urgente
El parche oficial (commit a664bf3d603d) revierte algif_aead.c a operación AEAD out-of-place, eliminando completamente la optimización in-place de 2017. El fix ataca la causa raíz: separa permanentemente la TX scatterlist (que puede contener páginas de page cache) de la RX scatterlist (el buffer de salida del usuario). El código histórico que ataba ambas con sg_chain() ya no existe.
La cronología de divulgación: Theori reportó al equipo de seguridad del kernel el 23 de marzo de 2026, los parches se commitearon a mainline el 1 de abril, la CVE se asignó el 22 de abril, y la divulgación pública fue el 29 de abril. Debian, Ubuntu, SUSE y otras distribuciones han publicado parches. Red Hat inicialmente dijo que iba a diferir el fix pero después cambió la guía para parchear con el resto. Ubuntu 26.04 (Resolute) y kernels posteriores no están afectados.
La mitigación interim del CERT-EU mientras se aplican parches: deshabilitar el módulo algif_aead persistentemente con echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf seguido de rmmod algif_aead 2>/dev/null || true. Este workaround no afecta a dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS o SSH. Para entornos containerizados, CERT-EU recomienda bloquear creación de sockets AF_ALG vía políticas seccomp en todos los workloads y pipelines, independientemente del estado del parche. Esto previene la explotación incluso en kernels sin parchear.
Mi valoración
Copy Fail es uno de los bugs más significativos del kernel Linux desde Dirty Pipe en 2022, y lo que más me convence del análisis es que el método de descubrimiento (auditoría de código asistida por IA en una hora) cambia las suposiciones sobre presupuestos de seguridad. Si descubrir un zero-day universal de kernel cuesta una hora en lugar de meses, la suposición de que los bugs de esta categoría son escasos (porque encontrarlos es caro) está desactualizada. Los equipos de seguridad que prioricen patches y monitoring asumiendo escasez van a fallar. Lo que más me preocupa es la combinación de portabilidad universal con explotación trivial. El script de 732 bytes funciona idéntico en Ubuntu 24.04, Amazon Linux, RHEL y SUSE sin recompilación. Eso significa que cualquier atacante con acceso de usuario local (a través de una vulnerabilidad de aplicación web, un container comprometido, un servicio expuesto con autenticación débil) puede escalar a root inmediatamente. La cadena de ataque mínima viable se ha reducido drásticamente: un bug en una app web + Copy Fail = compromiso completo del servidor. Los entornos multi-tenant con kernel compartido (la mayoría de hostings, muchas plataformas SaaS, casi todos los Kubernetes en producción) están particularmente expuestos. Lo más estructuralmente significativo es lo que el caso revela sobre la sostenibilidad de la confianza en kernels mantenidos colaborativamente. Tres cambios razonables (la optimización in-place de 2017, el uso de splice path con page cache, el scratch write de authencesn) entraron al kernel en distintos momentos y por distintas razones legítimas. Nadie conectó las tres decisiones, y la vulnerabilidad existió silenciosamente durante casi una década. La premisa de «many eyes make all bugs shallow» (muchos ojos vuelven todos los bugs superficiales) que sostiene la confianza en open source asume que la vigilancia humana escala. La realidad de Copy Fail sugiere lo contrario: la complejidad del kernel ha crecido más rápido que la capacidad de revisión humana, y los bugs ya no son superficiales sino profundos. La pregunta a 12 meses no es si habrá más Copy Fails (los va a haber, varios al año) sino si Linux adopta auditoría continua asistida por IA cómo parte del proceso de mainline merge. Mi predicción es que veremos integración de herramientas tipo Xint Code en pipelines de revisión kernel antes del cierre de 2026, no cómo reemplazo de revisores humanos sino cómo filtro adicional. Los reguladores europeos de infraestructura crítica probablemente exijan ese tipo de auditoría asistida por IA para cualquier kernel desplegado en sectores sensibles, antes de que el primer banco grande sufra un ransomware basado en Copy Fail u otro bug equivalente.
Preguntas frecuentes
¿Cómo sé si mi sistema es vulnerable? Cualquier kernel Linux desde 4.14 (julio de 2017) hasta 6.18.21 o 6.19.11 es vulnerable, salvo que el parche esté aplicado. Verifica la versión con uname -r. Comprueba el blog de seguridad de tú distribución (Ubuntu, Debian, RHEL, SUSE) para confirmar si el parche está disponible y aplicado. Ubuntu 26.04 (Resolute) y kernels posteriores no están afectados.
¿Qué hago si no puedo parchear inmediatamente? Aplica la mitigación recomendada por CERT-EU: deshabilita el módulo algif_aead con echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf y luego rmmod algif_aead 2>/dev/null || true. Este workaround no afecta a dm-crypt/LUKS, kTLS, IPsec, OpenSSL, GnuTLS, NSS ni SSH. Para entornos containerizados, bloquea AF_ALG con políticas seccomp.
¿Puede explotarse Copy Fail remotamente? No directamente. Copy Fail requiere ejecución de código local (acceso de usuario shell). Pero es trivial encadenarlo con vulnerabilidades remotas: un bug en una aplicación web que permita ejecución de código + Copy Fail = root. Los entornos multi-tenant (hostings, Kubernetes, contenedores compartidos) son particularmente vulnerables porque la page cache es compartida entre procesos del host. La industria del hosting acumula contratiempos en 2026: la vulnerabilidad crítica de cPanel CVE-2026-41940 que afectó a millones de webs es el caso más reciente que demuestra cómo un único bug puede comprometer infraestructura compartida a escala global.
Preguntas frecuentes
¿Qué es Copy Fail y por qué se considera grave?
Copy Fail es una vulnerabilidad del kernel Linux en el subsistema crypto AF_ALG que permite escalar privilegios a root con un script de 732 bytes. Afecta a la implementación AEAD in-place introducida en 2017 y vive en distribuciones mayoritarias (Ubuntu, RHEL, SUSE, Amazon Linux). Su gravedad viene de que es un único bug, fiable, sin race conditions, sin retries, que funciona sin modificación entre distribuciones.
¿Cuántos sistemas afecta y cuál es el alcance real?
Cualquier kernel Linux con la patch original de 2017 (algif_aead.c, commit 72548b093ee3) es vulnerable hasta aplicar el parche, lo que abarca prácticamente todas las distribuciones de servidor de la última década. Servidores cloud, contenedores Kubernetes, hostings compartidos y cualquier sistema con soporte AF_ALG cargado están en el radar.
¿Cómo se aplica el parche y qué hacer mientras tanto?
El parche oficial revierte la optimización in-place en algif_aead.c y se distribuye vía actualizaciones de kernel de cada distribución. Cómo mitigación temporal, deshabilitar AF_ALG bloqueando los módulos con modprobe blacklist o aplicar políticas seccomp en contenedores cierra la superficie de ataque sin necesidad de reiniciar todo el parque. La operación de cripto en userland (OpenSSL, GnuTLS, libsodium) no se ve afectada.
¿Puede explotarse Copy Fail de forma remota?
No directamente. Copy Fail requiere ejecución de código local con acceso de usuario shell, no es un RCE en sí mismo. Pero es trivial encadenarlo con vulnerabilidades remotas: un bug en una aplicación web que permita ejecución de código combinado con Copy Fail otorga root al atacante. En hostings compartidos y entornos multi-tenant el riesgo se multiplica porque la page cache es compartida entre procesos del host.
☞ El artículo completo original de Natalia Polo lo puedes ver
aquí
