• 06/05/2026 15:35

CISA alerta de explotación activa de Copy Fail para obtener root en Linux

Tiempo estimado de lectura: 4 minutos, 6 segundos

CVE-2026-31431 (Copy Fail) ya se está explotando de forma activa para lograr root en sistemas Linux, lo que ha llevado a CISA a incluirla en su catálogo KEV. El fallo permite a un usuario local sin privilegios escalar a administrador mediante una escritura controlada en memoria, por lo que la prioridad es parchear el kernel y reforzar controles en cloud y Kubernetes.

Entry image

La seguridad del kernel de Linux vuelve a estar en el foco por una escalada local de privilegios que, aun sin ser un fallo remoto por sí sola, se convierte en un multiplicador de impacto cuando un atacante ya ha conseguido ejecutar algo en el sistema. Esa es la situación con CVE-2026-31431, apodada Copy Fail, que se ha incorporado al catálogo Known Exploited Vulnerabilities (KEV) de CISA tras confirmarse su uso en ataques reales, con una fecha límite de mitigación marcada para el 15 de mayo de 2026 en organismos FCEB.

El defecto permite pasar de un usuario sin privilegios a root manipulando la page cache del kernel. El punto crítico es que el atacante puede forzar una escritura controlada de 4 bytes sobre páginas en caché asociadas a cualquier fichero que pueda leer, incluidos binarios setuid. En la práctica, se habilita la ejecución de código con privilegios elevados sin necesidad de modificar el archivo en disco, lo que complica algunas comprobaciones clásicas basadas en integridad de ficheros. Además, como el cambio reside en memoria, un reinicio puede borrar el rastro en la caché, sin que eso elimine la necesidad de investigar un posible compromiso.

A nivel técnico, el problema se relaciona con el subsistema criptográfico y la interfaz algif_aead, mediante el uso de AF_ALG combinado con splice(). La cadena de explotación publicada en código de prueba se apoya en crear un socket AF_ALG con una construcción del tipo authencesn(hmac(sha256),cbc(aes)), después ‘canalizar’ páginas de la page cache hacia una tubería criptográfica, y finalmente provocar una escritura en memoria a través de recvmsg(), controlando el valor de esos 4 bytes mediante datos AAD. La vulnerabilidad se introdujo en 2017 con un cambio que optimizaba el procesado AEAD sobre el propio buffer, lo que acabó permitiendo que páginas de caché terminasen en una scatterlist de destino escribible. La corrección upstream revierte esa optimización y se ha propagado a ramas estables mediante backports.

El alcance es amplio: se describe afectación en kernels publicados desde 2017, con rangos citados como 4.14 hasta 7.0 rc, además de 6.18.x anteriores a 6.18.22 y 6.19.x anteriores a 6.19.12. También se mencionan arreglos en ramas LTS adicionales, como 6.12.85, 6.6.137, 6.1.170, 5.15.204 y 5.10.254. En cuanto a distribuciones, se han mostrado ejemplos de impacto en Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 y SUSE 16, y se citan además Debian, Fedora, Arch Linux, Rocky Linux, AlmaLinux y Oracle Linux como entornos a vigilar, siempre condicionados a la versión concreta del kernel y a los parches del proveedor.

Aunque el vector es local y no requiere interacción del usuario, su peligrosidad crece cuando se combina con un acceso inicial, por ejemplo credenciales SSH expuestas, ejecución maliciosa en CI/CD o una primera intrusión dentro de un contenedor. En cloud, Docker, LXC y, sobre todo, Kubernetes, el riesgo aumenta porque los contenedores comparten el kernel del host. Un solo nodo vulnerable puede ampliar el radio de impacto del clúster, y un incidente que empiece como ejecución en contenedor puede escalar a compromiso del host si se dan las condiciones.

La mitigación principal es directa: actualizar el kernel a versiones corregidas, como 6.18.22, 6.19.12 o 7.0, o instalar los paquetes equivalentes publicados por cada distribución. En paralelo, conviene inventariar qué hosts siguen en versiones vulnerables, incluyendo imágenes cloud, plantillas de VMs y bases de imágenes de contenedor, porque una cadena de suministro interna con kernels antiguos puede reintroducir el riesgo al escalar entornos.

Si el parche no es inmediato, hay mitigaciones alternativas con matices importantes. En Ubuntu se ha desplegado una mitigación a nivel de paquete kmod para impedir la carga de algif_aead, y se considera que Ubuntu 26.04 no está afectada. Aun así, bloquear o descargar algif_aead puede causar regresiones de rendimiento o incompatibilidades en aplicaciones que dependan de esa ruta criptográfica, y puede requerir reinicio para garantizar que el sistema cae a cifrado en espacio de usuario. Antes de deshabilitar AF_ALG o algif_aead, es recomendable identificar dependencias reales, por ejemplo revisando procesos con lsof y filtrando uso de AF_ALG, para evitar romper servicios críticos.

En entornos Red Hat y derivados, puede ocurrir que el componente afectado esté integrado en el kernel y no sea bloqueable como módulo. En esos casos se plantea mitigación con parámetros de arranque como initcall_blacklist=algif_aead_init o initcall_blacklist=af_alg_init, planificando un reinicio controlado y validando después el arranque y el comportamiento de cargas que usen criptografía.

La detección tampoco es trivial, porque la explotación se apoya en llamadas al sistema legítimas y en manipulación en memoria. Aun así, pueden desplegarse controles en tiempo de ejecución centrados en patrones anómalos, como reglas de Falco que alerten sobre creación de sockets AF_ALG de tipo SEQPACKET por procesos inesperados. Esta aproximación requiere ajuste con una allowlist, ya que kTLS puede usar AF_ALG en escenarios legítimos.

En Kubernetes y plataformas de contenedores, además de parchear el host, es recomendable reducir el margen de encadenamiento denegando la creación de sockets AF_ALG mediante perfiles seccomp a nivel de runtime y de pods, reforzar controles de admisión como Pod Security Admission o políticas equivalentes, y limitar contenedores privilegiados. Operativamente, cualquier señal de ejecución no autorizada en un contenedor debería tratarse como posible compromiso del host, acelerando la recreación o rotación de nodos y la rotación de credenciales.

La disponibilidad de un PoC reutilizable entre distribuciones, junto con la publicación de un módulo de Metasploit el 29 de abril de 2026, reduce la barrera de entrada para actores oportunistas y eleva la urgencia de remediación. Con el fallo ya explotándose de forma activa y con impacto potencial sobre flotas en cloud, la respuesta más efectiva sigue siendo una combinación de parcheo rápido, endurecimiento de acceso, controles sobre ejecución de cargas y monitorización específica de actividad relacionada con AF_ALG, splice() y comportamientos inusuales en el kernel.

Más información

La entrada CISA alerta de explotación activa de Copy Fail para obtener root en Linux se publicó primero en Una Al Día.


Artículo de Hispasec publicado en https://unaaldia.hispasec.com/2026/05/cisa-alerta-de-explotacion-activa-de-copy-fail-para-obtener-root-en-linux.html?utm_source=rss&utm_medium=rss&utm_campaign=cisa-alerta-de-explotacion-activa-de-copy-fail-para-obtener-root-en-linux