La seguridad de Linux afronta una de esas vulnerabilidades que obligan a los administradores a actuar sin esperar al siguiente ciclo cómodo de mantenimiento. CVE-2026-31431, conocida como Copy Fail, afecta al kernel y permite que un usuario local sin privilegios pueda elevar permisos hasta root en sistemas vulnerables. El fallo ya ha sido incluido por CISA en su catálogo de vulnerabilidades explotadas activamente, una señal clara de que no se trata solo de una prueba académica ni de un aviso preventivo.
El detalle que vuelve especialmente incómodo este caso es la combinación de alcance, fiabilidad y disponibilidad pública del exploit. La vulnerabilidad requiere acceso local al sistema, por lo que no permite entrar desde Internet por sí sola. Pero en servidores multiusuario, entornos de hosting, runners de CI/CD, contenedores, máquinas de desarrollo compartidas o nodos Kubernetes, un acceso limitado puede bastar para tomar el control completo del host si el kernel no está corregido.
Un fallo en la interfaz criptográfica del kernel
Copy Fail se encuentra en algif_aead, una parte de la interfaz criptográfica del kernel Linux que expone algoritmos AEAD a espacio de usuario mediante sockets AF_ALG. Según el análisis técnico publicado por Xint, el problema permite a un usuario sin privilegios provocar una escritura controlada de cuatro bytes en la page cache de cualquier archivo legible del sistema. Esa page cache es una estructura de memoria usada por el kernel para acelerar lecturas de archivos.
El fallo procede de una optimización introducida en 2017 para operar “in-place”, es decir, reutilizando memoria de origen y destino en determinadas operaciones criptográficas. La corrección del kernel revierte esa complejidad y vuelve a operar “out-of-place”, porque no había beneficio suficiente para asumir ese diseño cuando origen y destino proceden de mapeos distintos. NVD recoge precisamente esa explicación en la descripción oficial del CVE.
En términos prácticos, el exploit público puede alterar en memoria la representación de un binario con permisos especiales, como su, sin modificar el archivo en disco. Después, al ejecutar ese binario, el sistema lee la versión ya corrompida en la page cache y el atacante obtiene privilegios de root. Xint afirma que su PoC funciona de forma determinista, sin condiciones de carrera ni ajustes específicos por distribución, y que fue verificado en sistemas como Ubuntu, Amazon Linux, RHEL y SUSE.
Este punto es importante para entender la gravedad. Muchas escaladas locales requieren una combinación delicada de versión concreta, offsets, timing o recompilación. Copy Fail, según los investigadores, reduce mucho esa barrera. Microsoft Defender también señala que el fallo afecta a múltiples distribuciones principales, puede facilitar escapes de contenedores y compromisos en entornos compartidos, y resulta especialmente preocupante en cloud, CI/CD y Kubernetes.
Por qué un fallo local puede ser tan grave
La palabra “local” puede llevar a engaño. En seguridad, una vulnerabilidad local no siempre es menor. Si un atacante ya ha conseguido una cuenta limitada, ha comprometido una aplicación web, ha ejecutado código en un contenedor o ha logrado lanzar una tarea dentro de un runner de integración continua, una escalada local puede convertir ese acceso inicial en control total del sistema.
En entornos de contenedores el riesgo es mayor porque los contenedores comparten el kernel del host. Si el kernel es vulnerable y el atacante puede abrir la interfaz necesaria desde el contenedor, la barrera entre contenedor y host puede quedar debilitada. Xint advierte de que la primitive cruza límites de contenedor porque la page cache se comparte en el host, y CERT-EU recomienda priorizar Kubernetes y runners de CI/CD expuestos a cargas no confiables.
CISA añadió CVE-2026-31431 a su Known Exploited Vulnerabilities Catalog el 1 de mayo de 2026 bajo la descripción “Linux Kernel Incorrect Resource Transfer Between Spheres Vulnerability”. Su inclusión obliga a las agencias federales civiles de Estados Unidos a remediar el fallo dentro del plazo marcado por la directiva BOD 22-01 y sirve como referencia para que el resto de organizaciones prioricen el parcheo.
El momento de la divulgación ha generado debate. En la lista oss-security de Openwall se señaló que el fallo empezó a circular con un exploit funcional y que algunos mantenedores no habían recibido margen suficiente para tener parches preparados en todas las ramas. CERT-EU indicó el 30 de abril que, en ese momento, varias distribuciones todavía no habían publicado paquetes de kernel corregidos, aunque el parche principal ya estaba integrado en upstream desde el 1 de abril.
Qué sistemas están afectados y qué deben hacer los administradores
El fallo afecta a kernels Linux construidos a partir de la optimización introducida en 2017 y hasta las versiones corregidas. Sysdig sitúa el rango vulnerable desde Linux 4.14 hasta versiones previas a 6.18.22 y 6.19.12, además de ramas LTS donde los distribuidores hayan incorporado el código afectado mediante backports. También enumera como probadas distribuciones como Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 y SUSE 16.
La respuesta principal es sencilla: actualizar el kernel con el paquete corregido de cada distribución y reiniciar. Reiniciar no es un trámite menor. En Linux, instalar un kernel nuevo no protege el sistema hasta que la máquina arranca con esa versión o se aplica una solución de live patching fiable. SUSE, por ejemplo, ya publicó una actualización para SLES 16.0 y pidió reiniciar tras instalarla.
Cuando no haya parche disponible o no sea posible reiniciar de inmediato, CERT-EU recomienda una mitigación temporal: deshabilitar el módulo algif_aead y bloquear la creación de sockets AF_ALG en contenedores mediante políticas seccomp, AppArmor o SELinux. La propia advertencia europea señala que deshabilitar algif_aead no debería afectar a usos comunes como LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS o SSH, aunque sí puede impactar en aplicaciones que usen explícitamente el motor afalg o sockets criptográficos directos.
Para equipos de seguridad, la mitigación debe ir acompañada de inventario. Hay que localizar servidores Linux, nodos Kubernetes, runners de CI/CD, hosts de contenedores, máquinas bastión, sistemas de hosting, appliances basados en Linux y entornos donde usuarios no privilegiados puedan ejecutar código. En estos últimos, Copy Fail debe tratarse como una prioridad alta, aunque el CVSS sea 7,8 y no una puntuación cercana a 10.
También conviene revisar señales de explotación, aunque no siempre será sencillo. Una de las características preocupantes del fallo es que la modificación puede quedar solo en memoria, sin cambiar el archivo en disco. Eso limita la utilidad de comprobaciones tradicionales basadas únicamente en hashes de archivos persistentes. Microsoft recomienda revisar actividad sospechosa y tratar cualquier ejecución no confiable en contenedores como posible vía de compromiso del host.
La publicación de Copy Fail deja una lección clara: la seguridad del kernel no es solo un asunto de escritorios Linux o servidores clásicos. Hoy el mismo kernel sostiene contenedores, pipelines de desarrollo, nodos cloud, sistemas embebidos, plataformas de hosting y entornos de IA donde se ejecuta código de terceros. Una escalada local fiable puede convertirse en una vía de ataque mucho más amplia cuando se combina con el modelo operativo actual.
El parche debe aplicarse cuanto antes. Y donde no pueda aplicarse de inmediato, hay que reducir superficie: limitar usuarios locales, bloquear sockets AF_ALG donde no sean necesarios, endurecer contenedores, reciclar nodos comprometidos y evitar que trabajos no confiables se ejecuten sobre kernels vulnerables. En este caso, esperar a “la próxima ventana” puede ser demasiado tarde.
Preguntas frecuentes
¿Qué es Copy Fail?
Copy Fail es el nombre dado a CVE-2026-31431, una vulnerabilidad del kernel Linux en algif_aead que permite a un usuario local sin privilegios escalar hasta root en sistemas vulnerables.
¿Es una vulnerabilidad explotable desde Internet?
No directamente. Requiere ejecución local de código. El riesgo aumenta si el atacante ya tiene una cuenta limitada, acceso a un contenedor, una aplicación comprometida o capacidad para ejecutar tareas en un runner de CI/CD.
¿Qué sistemas Linux pueden estar afectados?
La vulnerabilidad afecta a muchas distribuciones con kernels basados en código introducido desde 2017, incluidas ramas usadas por Ubuntu, Amazon Linux, RHEL, SUSE, Fedora, Debian, Arch y otras, según el kernel y los backports aplicados.
¿Qué deben hacer los administradores?
Actualizar el kernel con el parche de su distribución y reiniciar. Si no hay parche inmediato, aplicar mitigaciones temporales como deshabilitar algif_aead o bloquear sockets AF_ALG mediante seccomp, AppArmor o SELinux en cargas no confiables.
