Hay vulnerabilidades que entran por una contraseña débil, por un puerto abierto o por una aplicación mal configurada. Pero hay otras mucho más interesantes técnicamente: nacen en una pequeña decisión interna del sistema operativo, permanecen dormidas durante años y, cuando alguien une las piezas adecuadas, se convierten en una escalada de privilegios crítica.

Eso es Copy Fail, identificada como CVE-2026-31431: una vulnerabilidad del kernel Linux que permite a un usuario local sin privilegios acabar ejecutando código como root. Fue divulgada públicamente el 29 de abril de 2026, aunque el origen del problema se remonta a 2017, cuando se introdujo una optimización en el módulo

del kernel. CERT-EU la clasifica como vulnerabilidad alta, con una puntuación CVSS 7.8. (CERT-EU)

La vulnerabilidad fue descubierta por el equipo de Theori, con un papel destacado del investigador Taeyang Lee, apoyándose en Xint Code, una herramienta de análisis de seguridad asistida por IA. Según el análisis técnico de Xint, la investigación comenzó con una intuición de Taeyang Lee sobre cómo interactuaban el subsistema criptográfico de Linux,

,

y datos respaldados por la page cache. (Xint)

La cronología es especialmente interesante. El fallo se comunicó al equipo de seguridad del kernel Linux el 23 de marzo de 2026. El 24 de marzo se recibió el acuse de recibo inicial. El 25 de marzo ya se estaban proponiendo y revisando parches. El arreglo principal se incorporó al kernel el 1 de abril de 2026, mediante el commit

. El identificador CVE-2026-31431 fue asignado el 22 de abril, y la divulgación pública llegó el 29 de abril de 2026. (Xint)

Lo llamativo es que Copy Fail no es un fallo “nuevo” en el sentido estricto. Es un fallo descubierto en 2026, pero introducido en 2017. Durante casi una década, muchas distribuciones Linux modernas han podido arrastrar esta debilidad en determinados kernels. La propia página del proyecto indica que afecta a kernels construidos entre 2017 y la disponibilidad del parche, y menciona pruebas directas en distribuciones como Ubuntu, Amazon Linux, RHEL y SUSE. (Xint)

La explicación didáctica sería esta: Linux utiliza memoria RAM para acelerar el acceso a archivos. Esa zona se conoce como page cache. Cuando un programa lee un archivo, el sistema no siempre vuelve al disco; muchas veces usa una copia en memoria. El archivo real puede estar intacto en el disco, pero la copia que el sistema está usando en RAM puede ser la que realmente se ejecuta o se lee en ese momento.

Copy Fail permite escribir de forma controlada unos bytes en esa copia en memoria. No modifica directamente el archivo original en disco, y por eso puede pasar desapercibido para comprobaciones clásicas de integridad basadas solo en comparar el fichero almacenado. Según Xint, el fallo permite una escritura controlada de 4 bytes en una página respaldada por la page cache, lo que puede terminar afectando a binarios con permisos especiales como

. (Xint)

La parte técnica está en la combinación de varios elementos:

, que permite a programas de usuario acceder a funciones criptográficas del kernel;

, que mueve datos entre descriptores de archivo sin copias tradicionales; y

, relacionado con operaciones criptográficas AEAD. El problema aparece cuando páginas de la page cache acaban dentro de una estructura que puede ser escrita por una operación criptográfica. En concreto, el fallo se asocia a una optimización “in-place” introducida en 2017. (Xint)

Dicho con una analogía sencilla: imagina que el sistema guarda una fotocopia rápida de un documento importante para no tener que ir siempre al archivador. El documento original sigue protegido, cerrado y aparentemente sin cambios. Pero si alguien consigue modificar la fotocopia que el sistema está usando, puede alterar el comportamiento sin tocar el documento original. Eso, aplicado a binarios críticos del sistema, es muy serio.

No es una vulnerabilidad remota directa. Es decir, no basta con que un servidor tenga Linux para que alguien desde Internet lo explote sin más. El atacante necesita poder ejecutar código localmente como usuario sin privilegios. Pero ahí es donde el riesgo se dispara en entornos modernos: servidores compartidos, contenedores, Kubernetes, runners de CI/CD, sandboxes de IA, servicios que ejecutan código de terceros o máquinas donde una vulnerabilidad web previa pueda dar acceso inicial. En esos escenarios, Copy Fail puede ser el segundo paso: primero entro como usuario limitado, después escalo a root. (Xint)

Por eso es tan relevante para administradores de sistemas y equipos DevOps. En una máquina Linux clásica, multiusuario o expuesta a procesos no confiables, una escalada local de privilegios puede convertir un incidente contenido en un compromiso total del sistema. En contenedores el impacto es aún más delicado, porque la page cache se comparte a nivel del host; por eso los investigadores hablan también de un posible vector de escape de contenedor o compromiso de nodo. (Xint)

La mitigación principal es clara: actualizar el kernel o aplicar los paquetes de seguridad de la distribución. En Ubuntu, Canonical recomienda revisar la versión del kernel con

, actualizar paquetes y reiniciar para asegurar que la mitigación quede cargada. También documenta una mitigación alternativa bloqueando el módulo

si no es posible actualizar inmediatamente. (Ubuntu)

Para comprobar la versión del kernel:

1
uname -r

En sistemas Ubuntu/Debian, el flujo habitual sería:

1
2
3
sudo apt update

sudo apt upgrade

sudo reboot

Y como mitigación temporal, si todavía no se puede actualizar:

1
2
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf

sudo rmmod algif_aead 2>/dev/null

La propia documentación de Ubuntu indica que reiniciar ayuda a asegurar que la mitigación se aplica correctamente, y que también se puede comprobar si el módulo sigue cargado en

. (Ubuntu)

La gran lección de Copy Fail es que una vulnerabilidad crítica no siempre está en una aplicación visible. A veces vive en una optimización interna del kernel, en una interacción inesperada entre subsistemas que, por separado, parecían razonables: criptografía, memoria, page cache y operaciones de copia eficientes.

También deja otra reflexión importante: la IA empieza a tener un papel real en la investigación de vulnerabilidades. En este caso, el hallazgo fue asistido por Xint Code, pero no fue “magia automática”: hubo criterio humano, intuición técnica y análisis experto. La IA ayudó a escalar la revisión del código, pero la comprensión del impacto siguió dependiendo de investigadores capaces de conectar piezas profundas del sistema operativo. (Xint)

En resumen, Copy Fail no es solo otra CVE más. Es el descubrimiento en 2026 de un fallo introducido en 2017, capaz de transformar una escritura aparentemente pequeña en memoria en una escalada completa a root. Para cualquier organización que use Linux en servidores, contenedores o plataformas cloud, el mensaje es claro: inventariar, actualizar, reiniciar y endurecer los entornos donde se ejecuta código no confiable.

Porque a veces, en seguridad, el problema no está en el archivo que ves en disco, sino en la copia que el sistema está usando en memoria.