{"id":15812,"date":"2026-05-01T17:48:25","date_gmt":"2026-05-01T15:48:25","guid":{"rendered":"https:\/\/www.palentino.es\/blog\/?p=15812"},"modified":"2026-05-01T17:49:26","modified_gmt":"2026-05-01T15:49:26","slug":"copy-fail-la-vulnerabilidad-de-linux-que-convierte-una-copia-en-memoria-en-acceso-root","status":"publish","type":"post","link":"https:\/\/www.palentino.es\/blog\/copy-fail-la-vulnerabilidad-de-linux-que-convierte-una-copia-en-memoria-en-acceso-root\/","title":{"rendered":"Copy Fail: la vulnerabilidad de Linux que convierte una copia en memoria en acceso root"},"content":{"rendered":"

Hay vulnerabilidades que entran por una contrase\u00f1a d\u00e9bil, por un puerto abierto o por una aplicaci\u00f3n mal configurada. Pero hay otras mucho m\u00e1s interesantes t\u00e9cnicamente: nacen en una peque\u00f1a decisi\u00f3n interna del sistema operativo, permanecen dormidas durante a\u00f1os y, cuando alguien une las piezas adecuadas, se convierten en una escalada de privilegios cr\u00edtica.<\/p>\n

Eso es Copy Fail<\/strong>, identificada como CVE-2026-31431<\/strong>: una vulnerabilidad del kernel Linux que permite a un usuario local sin privilegios acabar ejecutando c\u00f3digo como root<\/strong>. Fue divulgada p\u00fablicamente el 29 de abril de 2026<\/strong>, aunque el origen del problema se remonta a 2017<\/strong>, cuando se introdujo una optimizaci\u00f3n en el m\u00f3dulo<\/p>\n

1
<\/div><\/td>
algif_aead<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

del kernel. CERT-EU la clasifica como vulnerabilidad alta, con una puntuaci\u00f3n CVSS 7.8<\/strong>. (CERT-EU<\/a>)<\/p>\n

La vulnerabilidad fue descubierta por el equipo de Theori<\/strong>, con un papel destacado del investigador Taeyang Lee<\/strong>, apoy\u00e1ndose en Xint Code<\/strong>, una herramienta de an\u00e1lisis de seguridad asistida por IA. Seg\u00fan el an\u00e1lisis t\u00e9cnico de Xint, la investigaci\u00f3n comenz\u00f3 con una intuici\u00f3n de Taeyang Lee sobre c\u00f3mo interactuaban el subsistema criptogr\u00e1fico de Linux,<\/p>\n

1
<\/div><\/td>
AF_ALG<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

,<\/p>\n

1
<\/div><\/td>
splice()<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

y datos respaldados por la page cache<\/strong>. (Xint<\/a>)<\/p>\n

La cronolog\u00eda es especialmente interesante. El fallo se comunic\u00f3 al equipo de seguridad del kernel Linux el 23 de marzo de 2026<\/strong>. El 24 de marzo<\/strong> se recibi\u00f3 el acuse de recibo inicial. El 25 de marzo<\/strong> ya se estaban proponiendo y revisando parches. El arreglo principal se incorpor\u00f3 al kernel el 1 de abril de 2026<\/strong>, mediante el commit<\/p>\n

1
<\/div><\/td>
a664bf3d603d<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

. El identificador CVE-2026-31431<\/strong> fue asignado el 22 de abril<\/strong>, y la divulgaci\u00f3n p\u00fablica lleg\u00f3 el 29 de abril de 2026<\/strong>. (Xint<\/a>)<\/p>\n

Lo llamativo es que Copy Fail no es un fallo \u201cnuevo\u201d en el sentido estricto. Es un fallo descubierto en 2026<\/strong>, pero introducido en 2017<\/strong>. Durante casi una d\u00e9cada, muchas distribuciones Linux modernas han podido arrastrar esta debilidad en determinados kernels. La propia p\u00e1gina 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<\/a>)<\/p>\n

<\/p>\n

La explicaci\u00f3n did\u00e1ctica ser\u00eda esta: Linux utiliza memoria RAM para acelerar el acceso a archivos. Esa zona se conoce como page cache<\/strong>. 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\u00e1 usando en RAM puede ser la que realmente se ejecuta o se lee en ese momento.<\/p>\n

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\u00e1sicas de integridad basadas solo en comparar el fichero almacenado. Seg\u00fan Xint, el fallo permite una escritura controlada de 4 bytes en una p\u00e1gina respaldada por la page cache, lo que puede terminar afectando a binarios con permisos especiales como<\/p>\n

1
<\/div><\/td>
\/usr\/bin\/su<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

. (Xint<\/a>)<\/p>\n

La parte t\u00e9cnica est\u00e1 en la combinaci\u00f3n de varios elementos:<\/p>\n

1
<\/div><\/td>
AF_ALG<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

, que permite a programas de usuario acceder a funciones criptogr\u00e1ficas del kernel;<\/p>\n

1
<\/div><\/td>
splice()<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

, que mueve datos entre descriptores de archivo sin copias tradicionales; y<\/p>\n

1
<\/div><\/td>
algif_aead<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

, relacionado con operaciones criptogr\u00e1ficas AEAD. El problema aparece cuando p\u00e1ginas de la page cache acaban dentro de una estructura que puede ser escrita por una operaci\u00f3n criptogr\u00e1fica. En concreto, el fallo se asocia a una optimizaci\u00f3n \u201cin-place\u201d introducida en 2017. (Xint<\/a>)<\/p>\n

Dicho con una analog\u00eda sencilla: imagina que el sistema guarda una fotocopia r\u00e1pida 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\u00e1 usando, puede alterar el comportamiento sin tocar el documento original. Eso, aplicado a binarios cr\u00edticos del sistema, es muy serio.<\/p>\n

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\u00e1s. El atacante necesita poder ejecutar c\u00f3digo localmente como usuario sin privilegios. Pero ah\u00ed es donde el riesgo se dispara en entornos modernos: servidores compartidos, contenedores, Kubernetes, runners de CI\/CD, sandboxes de IA, servicios que ejecutan c\u00f3digo de terceros o m\u00e1quinas 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\u00e9s escalo a root. (Xint<\/a>)<\/p>\n

Por eso es tan relevante para administradores de sistemas y equipos DevOps. En una m\u00e1quina Linux cl\u00e1sica, 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\u00fan m\u00e1s delicado, porque la page cache se comparte a nivel del host; por eso los investigadores hablan tambi\u00e9n de un posible vector de escape de contenedor o compromiso de nodo. (Xint<\/a>)<\/p>\n

La mitigaci\u00f3n principal es clara: actualizar el kernel o aplicar los paquetes de seguridad de la distribuci\u00f3n<\/strong>. En Ubuntu, Canonical recomienda revisar la versi\u00f3n del kernel con<\/p>\n

1
<\/div><\/td>
uname -r<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

, actualizar paquetes y reiniciar para asegurar que la mitigaci\u00f3n quede cargada. Tambi\u00e9n documenta una mitigaci\u00f3n alternativa bloqueando el m\u00f3dulo<\/p>\n

1
<\/div><\/td>
algif_aead<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n

si no es posible actualizar inmediatamente. (Ubuntu<\/a>)<\/p>\n

Para comprobar la versi\u00f3n del kernel:<\/p>\n

\n\n
1
<\/div><\/td>
uname -r<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n<\/pre>\n
En sistemas Ubuntu\/Debian, el flujo habitual ser\u00eda:<\/p>\n
\n\n
1
2
3
<\/div><\/td>
sudo apt update
\nsudo apt upgrade
\nsudo reboot<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n<\/pre>\n
Y como mitigaci\u00f3n temporal, si todav\u00eda no se puede actualizar:<\/p>\n
\n\n
1
2
<\/div><\/td>
echo "install algif_aead \/bin\/false" | sudo tee \/etc\/modprobe.d\/manual-disable-algif_aead.conf
\nsudo rmmod algif_aead 2&gt;\/dev\/null<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n\n<\/pre>\n
La propia documentaci\u00f3n de Ubuntu indica que reiniciar ayuda a asegurar que la mitigaci\u00f3n se aplica correctamente, y que tambi\u00e9n se puede comprobar si el m\u00f3dulo sigue cargado en<\/p>\n
1
<\/div><\/td>
\/proc\/modules<\/div><\/td><\/tr><\/tbody><\/table><\/div>\n
. (Ubuntu<\/a>)<\/p>\n
La gran lecci\u00f3n de Copy Fail es que una vulnerabilidad cr\u00edtica no siempre est\u00e1 en una aplicaci\u00f3n visible. A veces vive en una optimizaci\u00f3n interna del kernel, en una interacci\u00f3n inesperada entre subsistemas que, por separado, parec\u00edan razonables: criptograf\u00eda, memoria, page cache y operaciones de copia eficientes.<\/p>\n
Tambi\u00e9n deja otra reflexi\u00f3n importante: la IA empieza a tener un papel real en la investigaci\u00f3n de vulnerabilidades. En este caso, el hallazgo fue asistido por Xint Code<\/strong>, pero no fue \u201cmagia autom\u00e1tica\u201d: hubo criterio humano, intuici\u00f3n t\u00e9cnica y an\u00e1lisis experto. La IA ayud\u00f3 a escalar la revisi\u00f3n del c\u00f3digo, pero la comprensi\u00f3n del impacto sigui\u00f3 dependiendo de investigadores capaces de conectar piezas profundas del sistema operativo. (Xint<\/a>)<\/p>\n
En resumen, Copy Fail no es solo otra CVE m\u00e1s<\/strong>. Es el descubrimiento en 2026 de un fallo introducido en 2017, capaz de transformar una escritura aparentemente peque\u00f1a en memoria en una escalada completa a root. Para cualquier organizaci\u00f3n que use Linux en servidores, contenedores o plataformas cloud, el mensaje es claro: inventariar, actualizar, reiniciar y endurecer los entornos donde se ejecuta c\u00f3digo no confiable.<\/p>\n
Porque a veces, en seguridad, el problema no est\u00e1 en el archivo que ves en disco, sino en la copia que el sistema est\u00e1 usando en memoria.<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Hay vulnerabilidades que entran por una contrase\u00f1a d\u00e9bil, por un puerto abierto o por una aplicaci\u00f3n mal configurada. Pero hay otras mucho m\u00e1s interesantes t\u00e9cnicamente: nacen en una peque\u00f1a decisi\u00f3n interna del sistema operativo, permanecen dormidas durante a\u00f1os y, cuando alguien une las piezas adecuadas, se convierten en una escalada de privilegios cr\u00edtica. 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\u00f3digo como root. Fue divulgada p\u00fablicamente el 29 de abril de 2026, aunque el origen del problema se remonta a 2017, cuando se introdujo una optimizaci\u00f3n en el m\u00f3dulo 1algif_aead del kernel. CERT-EU la clasifica como vulnerabilidad alta, con una puntuaci\u00f3n CVSS 7.8. (CERT-EU) La vulnerabilidad fue descubierta por el equipo de Theori, con un papel destacado del investigador Taeyang Lee, apoy\u00e1ndose en Xint Code, una herramienta de an\u00e1lisis de seguridad asistida por IA. Seg\u00fan el an\u00e1lisis t\u00e9cnico de Xint, la investigaci\u00f3n comenz\u00f3 con una intuici\u00f3n de Taeyang Lee sobre c\u00f3mo interactuaban el subsistema criptogr\u00e1fico de Linux, 1AF_ALG , 1splice() y datos respaldados por la page cache. (Xint) La cronolog\u00eda es especialmente interesante. El fallo se comunic\u00f3 al equipo de seguridad del kernel Linux el 23 de marzo de 2026. El 24 de marzo se recibi\u00f3 el acuse de recibo inicial. El 25 de marzo ya se estaban proponiendo y revisando parches. El arreglo principal se incorpor\u00f3 al kernel el 1 de abril de 2026, mediante el commit 1a664bf3d603d . El identificador CVE-2026-31431 fue asignado el 22 de abril, y la divulgaci\u00f3n p\u00fablica lleg\u00f3 el 29 de abril de 2026. (Xint) Lo llamativo es que Copy Fail no es un fallo \u201cnuevo\u201d en el sentido estricto. Es un fallo descubierto en 2026, pero introducido en 2017. Durante casi una d\u00e9cada, muchas distribuciones Linux modernas han<\/p>\n
(M\u00e1s)\u2026<\/a><\/p>\n","protected":false},"author":1,"featured_media":12506,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1415],"tags":[],"class_list":["post-15812","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categoria-es"],"_links":{"self":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/15812","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/comments?post=15812"}],"version-history":[{"count":3,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/15812\/revisions"}],"predecessor-version":[{"id":15815,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/15812\/revisions\/15815"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/media\/12506"}],"wp:attachment":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/media?parent=15812"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/categories?post=15812"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/tags?post=15812"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}