Copy Fail: la vulnerabilidad crítica del kernel Linux (CVE-2026-31431) ya explotada que podría dar acceso root y romper el aislamiento en contenedores

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha incluido en su catálogo Known Exploited Vulnerabilities (KEV) una vulnerabilidad crítica recientemente divulgada en el núcleo Linux, registrada como CVE‑2026‑31431 (CVSS 7.8), después de que investigadores y empresas de seguridad reportaran pruebas de explotación activo. Se trata de un fallo de elevación de privilegios local (LPE) apodado "Copy Fail", que permite a un usuario sin privilegios lograr acceso root manipulando la caché de páginas en memoria del kernel; los parches que corrigen el problema ya se han integrado en las ramas del kernel señaladas por los mantenedores, incluyendo las versiones 6.18.22, 6.19.12 y 7.0.

En términos técnicos, el error es una corrupción controlada del page cache, que afecta la forma en que el kernel copia recursos entre “esferas” internas del subsistema criptográfico (AF_ALG). Al corromper bytes concretos en la caché de un ejecutable en memoria —sin tocar el disco— un atacante puede inyectar instrucciones en binarios privilegiados setuid (por ejemplo /usr/bin/su) y obtener ejecución con UID 0. Los autores del informe explican que el bug surge de tres cambios aparentemente inocuos introducidos en 2011, 2015 y 2017, por lo que la falla está presente en kernels distribuidos desde entonces y es explotable de forma fiable con un PoC muy compacto en Python (además de implementaciones detectadas en Go y Rust).

La disponibilidad pública de un PoC y la naturaleza local del vector hacen que el riesgo sea particularmente alto en entornos donde se puede encadenar un acceso inicial: una cuenta SSH comprometida, un job de CI malicioso, o una fuga dentro de un contenedor pueden servir como punto de partida. Empresas de seguridad advierten que la detección es compleja porque la explotación usa llamadas de sistema legítimas, lo que dificulta distinguir actividad maliciosa de comportamiento normal. El escenario más peligroso es el de entornos en nube y contenedores, donde Docker, LXC o Kubernetes pueden exponer el subsistema AF_ALG en el host si el módulo algif_aead está cargado, lo que reduce barreras y permite romper el aislamiento de contenedores para comprometer el host físico.

Ante este escenario real, la prioridad número uno para administradores y responsables de seguridad debe ser parchear cuanto antes. CISA ha marcado esta vulnerabilidad como explotada y ha recomendado aplicar las actualizaciones de los proveedores; además, las agencias federales estadounidenses han recibido una fecha límite interna (May 15, 2026) para mitigar el riesgo. Puede consultar la inclusión en el catálogo KEV y los avisos oficiales en la página de CISA: https://www.cisa.gov/known-exploited-vulnerabilities-catalog, y revisar la entrada registrada en MITRE para más contexto técnico: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-31431.

Si no es posible actualizar inmediatamente, existen medidas compensatorias que reducen la superficie de exposición: evitar que el host cargue el módulo algif_aead (por ejemplo descargar o bloquear su carga con políticas de módulos), aislar sistemas con control de acceso a red y segmentación para minimizar puertas de entrada explotables, revisar permisos y acceso SSH, y endurecer configuraciones de contenedores (evitar privilegios elevados, usar perfiles seccomp/SELinux/AppArmor y negar acceso directo a subsistemas kernel no necesarios). Tenga en cuenta que las soluciones de integridad de ficheros tradicionales pueden no detectar esta técnica porque el ejecutable nunca se modifica en disco; por ello, la prevención y el parcheo son más fiables que la detección posterior.

También conviene reforzar la telemetría y la respuesta: activar y revisar logs de auditoría, monitorizar procesos que cambian a UID 0, desplegar capacidades EDR/NGAV que correlacionen anomalías locales y preparar playbooks de contención para incidentes que impliquen escalada de privilegios en hosts o nodos de orquestación. Los equipos que gestionan imágenes de contenedores deberían regenerar y redeplegar imágenes sobre kernels parcheados y revisar pipelines de CI para evitar ejecuciones no confiables que puedan actuar como punto inicial de explotación.

El alcance de esta vulnerabilidad, su sencillez de explotación con un PoC disponible y su impacto potencial en entornos multiusuario y cloud hacen que no sea una amenaza teórica: si su infraestructura usa Linux (especialmente en contenedores o sistemas compartidos), debe actuar ya. Para comprobar si su organización dispone de parches o mitigaciones aplicadas, consulte las políticas y boletines de su distribuidor y verifique la versión del kernel en los hosts afectados; la página oficial del kernel y los repositorios de su distribución son puntos de partida prácticos: https://www.kernel.org.