Linux tiene fama de sistema robusto. No invulnerable, claro, pero sí especialmente resistente, hasta el punto de haberse convertido en una de las bases silenciosas de Internet, de los servidores empresariales y de muchos entornos donde la seguridad es parte del contrato. Por eso una vulnerabilidad como CopyFail resulta especialmente seria: no hablamos de un fallo menor en una aplicación aislada, sino de un problema en el kernel que puede permitir que alguien que ya ejecuta código con pocos permisos acabe obteniendo acceso root.
CopyFail. La vulnerabilidad, identificada como CVE-2026-31431, salió a la luz cuando la firma Theori hizo públicos los detalles del fallo y el código de explotación tras haber avisado cinco semanas antes al equipo de seguridad del kernel de Linux. Ese matiz temporal es importante porque el kernel ya había recibido parches en varias ramas, desde 7.0 hasta 5.10.254. Lo que no había ocurrido todavía, al menos de forma generalizada, era su traslado efectivo a muchas distribuciones Linux.
De qué estamos hablando. CopyFail es una escalada local de privilegios. No significa que cualquiera pueda atacar desde fuera una máquina Linux sin más, sino que alguien que ya puede ejecutar código dentro del sistema con permisos limitados, por ejemplo desde una cuenta normal, un servicio web comprometido, un contenedor o un trabajo de CI/CD, puede intentar escalar hasta root. En Linux, root es la cuenta con control administrativo completo. Por eso el riesgo no está en la primera puerta de entrada, sino en lo que ocurre justo después: un acceso acotado puede convertirse en control del sistema.
Un exploit demasiado fiable. Hay otro elemento que explica la alarma. Muchas vulnerabilidades del kernel dependen de condiciones muy concretas para funcionar, como una corrupción de memoria que puede variar según la versión, la distribución o incluso la máquina. CopyFail parte de un fallo lógico en la API criptográfica del kernel, y eso cambia el terreno. Los investigadores de Bugcrowd explican que al tratarse de un fallo lógico, el exploit no depende de ajustes internos tan específicos, un rasgo que reduce la fricción para los atacantes y complica el trabajo de los defensores.
El parche. El caso también deja una lección sobre cómo se coordinan las vulnerabilidades en Linux. Como mencionamos arriba, Theori comunicó el fallo al equipo de seguridad del kernel cinco semanas antes de darlo a conocer públicamente. El problema es que, para la mayoría de los usuarios, las correcciones no llegan directamente, sino a través de distribuciones que empaquetan, prueban y publican sus propios parches o mitigaciones. Cuando el exploit se hizo público, ese proceso aún no había terminado en muchas distribuciones o versiones, dejando una ventana de exposición difícil de ignorar.
Situación actual. Con los días, parte del ecosistema ha empezado a cerrar la brecha, pero no de una forma uniforme. Al momento de publicar este artículo, distribuciones como Debian, Arch, Fedora, SUSE y Amazon Linux ya habían publicado parches o avisos para determinadas ramas, mientras que Ubuntu insistía en actualizar el sistema y aplicar mitigaciones si el kernel corregido aún no estaba disponible o no se había cargado tras un reinicio.
Imágenes | Xataka con Nano Banana
–
La noticia
Pensábamos que Linux era un sistema operativo “blindado”: una vulnerabilidad acaba de sacudir casi todas sus versiones
fue publicada originalmente en
Xataka
por
Javier Marquez
.
