Copy Fail (CVE-2026-31431): explotación activa y riesgos en Linux

CISA ha añadido la vulnerabilidad CVE-2026-31431 (Copy Fail) en el kernel de Linux a su catálogo de vulnerabilidades explotadas CISA KEV, confirmando su explotación activa: este fallo, con una puntuación CVSS de 7.8, permite que cualquier usuario local sin privilegios obtenga permisos de root mediante la corrupción de ejecutables almacenados en caché en memoria, incluidos binarios setuid, lo que hace crítico actualizar inmediatamente las distribuciones Linux (especialmente en entornos cloud y de contenedores) a versiones del kernel que ya incluyan la corrección.

Detalles técnicos de la vulnerabilidad

Copy Fail (CVE-2026-31431), descrita en la entrada NVD CVE-2026-31431, es una vulnerabilidad de elevación local de privilegios en la sub‑sistema de plantillas criptográficas de autenticación del kernel de Linux. CISA la define como una transferencia incorrecta de recursos «entre dominios», lo que en la práctica se traduce en la posibilidad de que un proceso de usuario influya en objetos situados en un dominio más privilegiado.

Hechos clave sobre la vulnerabilidad:

• Identificador: CVE-2026-31431 (Copy Fail)
• Puntuación: CVSS 7.8 (peligrosidad alta)
• Tipo: elevación local de privilegios (LPE) hasta root
• Vector: local (AV:L), bajos privilegios requeridos, sin interacción del usuario
• Sistemas afectados: distribuciones Linux suministradas desde 2017
• Correcciones: kernel de Linux versiones 6.18.22, 6.19.12 y 7.0

Los investigadores de Theori y Xint han mostrado que el problema no se originó por un único commit erróneo, sino por tres cambios en el kernel «seguros» de forma aislada, realizados en 2011, 2015 y 2017. En conjunto dieron lugar a un fallo lógico en el tratamiento de la plantilla criptográfica de autenticación, que puede explotarse de forma fiable mediante un exploit muy compacto (unos 732 bytes) escrito en Python. A partir de esta variante ya han aparecido implementaciones en Go y Rust, detectadas en repositorios públicos.

Una característica crítica de Copy Fail es el objeto de ataque: el page cache, es decir, la caché de páginas en memoria donde el kernel almacena el contenido de los archivos. La vulnerabilidad permite a un usuario sin privilegios corromper el contenido de las páginas en caché de cualquier archivo legible, incluidos binarios setuid. Como destaca Wiz, la página en caché es lo que realmente ejecuta la CPU al lanzar un binario, por lo que modificar el page cache equivale a alterar el programa en caliente sin escribir nada en disco.

De ahí se deriva un escenario típico de explotación:

• un atacante con acceso local al sistema utiliza la vulnerabilidad para modificar las páginas en cache correspondientes a un binario con privilegios (por ejemplo, /usr/bin/su);
• en las páginas modificadas se inyecta código arbitrario;
• al ejecutar el binario privilegiado se ejecuta ya el código modificado, lo que otorga al atacante permisos de root.

El exploit utiliza únicamente llamadas al sistema legítimas y no depende de condiciones de carrera ni de adivinar direcciones de memoria. Esto reduce de entrada la complejidad de explotación y dificulta su detección mediante soluciones basadas en comportamiento: desde el punto de vista del sistema, se parece al funcionamiento normal de una aplicación que usa la sub‑sistema criptográfica y trabaja con archivos.

Según Microsoft Defender Security Research Team, ya se está observando «actividad de pruebas preliminares» en torno a CVE-2026-31431, y CISA, al incluir la vulnerabilidad en el catálogo KEV, indica de forma explícita la existencia de explotación in-the-wild.

En esencia, esta técnica corresponde a un escenario típico de explotación de vulnerabilidades para elevar privilegios, que en términos de MITRE ATT&CK se encuadra en la explotación de vulnerabilidades locales de privilegios (Exploitation for Privilege Escalation).

Evaluación del impacto y perfil de riesgo

El posible impacto de Copy Fail viene determinado no tanto por la puntuación CVSS como por el contexto real de uso de Linux:

• Cloud y virtualización. Linux domina las infraestructuras cloud. Cualquier escenario en el que un atacante pueda ejecutar código en una máquina virtual o un contenedor (por ejemplo, a través de una filtración de claves SSH o de una aplicación web vulnerable) puede escalarse hasta el control total del sistema operativo invitado y, en determinadas condiciones, hasta ataques contra la plataforma host.
• Plataformas de contenedores (Docker, LXC, Kubernetes). Según Kaspersky, Copy Fail supone un riesgo elevado para entornos contenerizados, ya que los procesos dentro de un contenedor, por defecto, obtienen acceso a la sub‑sistema AF_ALG si el módulo algif_aead está cargado en el kernel del host. En ese caso, la explotación dentro del contenedor puede derivar en un escape del contenedor y la toma de control del host físico (o virtual), es decir, en la ruptura del modelo de aislamiento.
• Servidores de uso compartido y sistemas multi-tenant. Plataformas de formación, proveedores de hosting y cualquier entorno en el que distintos usuarios obtengan acceso shell al mismo host Linux se vuelven especialmente vulnerables: un solo usuario no controlado puede obtener root y comprometer los datos del resto de clientes.
• Infraestructura crítica y organismos gubernamentales. Para las agencias federales civiles de EE. UU. (FCEB), CISA ha fijado un plazo estricto para la instalación de parches: hasta el 15 de mayo de 2026. Esto refleja el riesgo para la integridad y disponibilidad de servicios críticos en caso de compromiso local exitoso.

Desde el punto de vista de los riesgos de negocio, las consecuencias de no actuar incluyen:

• toma de control completa del servidor con posibilidad de desplazamiento horizontal y vertical posterior dentro de la infraestructura;
• pérdida de confianza en la integridad de las aplicaciones: la inyección de código en binarios privilegiados puede emplearse como un mecanismo poco visible de persistencia a largo plazo y de evasión de controles de integridad que solo monitorizan el sistema de archivos;
• compromiso de los pipelines de CI/CD: si un atacante dispone de root en los agentes de build, puede modificar de forma imperceptible los artefactos generados;
• consecuencias regulatorias en incidentes en los que el acceso root se utilice para filtrar o destruir datos críticos o personales.

Recomendaciones prácticas de mitigación

1. Evaluación de la exposición

La prioridad inmediata es determinar qué sistemas pueden ser vulnerables:

• verifique la versión del kernel con el comando uname -r en servidores y estaciones de trabajo Linux;
• compare las versiones obtenidas con aquellas en las que ya se ha integrado la corrección (6.18.22, 6.19.12, 7.0) o con las actualizaciones publicadas por su proveedor de distribución;
• analice los entornos en los que exista la posibilidad de ejecutar código bajo cuentas con privilegios limitados: clústeres de contenedores, servidores con acceso SSH para desarrolladores, máquinas de CI.

En caso de duda, es aconsejable contrastar la información sobre CVE-2026-31431 en la base NVD y en la documentación del proveedor de la distribución o del kernel (por ejemplo, el sitio oficial kernel.org).

2. Gestión de parches y priorización

Orden de actuación recomendado para las actualizaciones:

1. Máxima prioridad (urgente): nodos en los que terceros o procesos maliciosos puedan obtener acceso a un shell local: servidores con acceso SSH público, nodos de Kubernetes, nodos con contenedores externos en ejecución, servidores de uso compartido.
2. Alta prioridad: agentes de CI/CD, servicios de infraestructura y bases de datos donde un compromiso de root pueda tener efectos en cadena.
3. Resto de sistemas: incluir la actualización del kernel en la próxima ventana de mantenimiento planificada.

Para las agencias FCEB el plazo lo marca CISA: hasta el 15 de mayo de 2026. Para organizaciones comerciales, resulta razonable orientarse por plazos similares: hablamos de días, no de meses.

3. Medidas temporales si no es posible actualizar de inmediato

Si no es posible actualizar el kernel con rapidez (por ejemplo, debido a limitaciones en las ventanas de parada):

• Deshabilite la funcionalidad vulnerable. CISA recomienda desactivar temporalmente la funcionalidad afectada. En la práctica esto significa limitar el uso de la sub‑sistema AF_ALG y de los módulos relacionados (en particular, algif_aead) conforme a las recomendaciones de su proveedor de distribución.
• Refuerce el aislamiento de red. Reduzca al mínimo la posibilidad de que un atacante obtenga acceso local: restrinja el acceso SSH solo vía VPN o desde direcciones de confianza, y endurezca las políticas de acceso a los bastion hosts.
• Revise la política de acceso en clústeres de contenedores. Limite la ejecución de contenedores no verificados en nodos donde aún no se haya instalado el kernel actualizado y, en la medida de lo posible, evite lanzar contenedores con privilegios excesivos y acceso a las sub‑sistemas criptográficas del kernel.
• Endurezca el control de cuentas. Minimice el número de usuarios con acceso interactivo a los sistemas y aplique el principio de mínimo privilegio a las cuentas de servicio.

4. Monitorización y detección

Dado que el exploit se basa exclusivamente en llamadas al sistema legítimas y no modifica archivos en disco, los controles tradicionales de integridad del sistema de archivos son poco eficaces. No obstante, son posibles algunas medidas complementarias:

• reforzar la auditoría del lanzamiento de binarios privilegiados (especialmente setuid) y del comportamiento anómalo de procesos con permisos de root;
• monitorizar el uso atípico de las sub‑sistemas criptográficas del kernel y de AF_ALG en entornos donde normalmente no son utilizadas por el software de aplicación;
• revisar las reglas de análisis de comportamiento en soluciones EDR / tipo EDR para Linux, añadiendo foco a la escalada inesperada de privilegios por parte de aplicaciones que se ejecutan bajo usuarios sin privilegios.

Conclusión clave: cualquier entorno en el que un posible atacante pueda ejecutar código en un host Linux vulnerable debe considerarse en riesgo de compromiso total mientras el kernel no se haya actualizado a una versión corregida frente a CVE-2026-31431 o no se haya deshabilitado la funcionalidad correspondiente. La medida más práctica es actualizar el kernel (o los paquetes de kernel de la distribución) a versiones que incluyan el parche en la próxima ventana de mantenimiento, dando prioridad a los hosts con contenedores, SSH público y escenarios multiusuario.