La semana de parches para administradores Linux ha llegado con una vulnerabilidad especialmente incómoda. CVE-2026-31431, conocida como Copy Fail, permite que un usuario local sin privilegios pueda escalar hasta root en sistemas afectados. No es un fallo remoto que pueda explotarse desde internet sin acceso previo, pero sí representa un escenario muy serio para servidores compartidos, entornos multiusuario, plataformas de hosting, nodos Kubernetes, pipelines CI/CD y máquinas donde cualquier cuenta limitada pueda ejecutar código.
El problema se encuentra en el subsistema criptográfico del kernel Linux, concretamente en algif_aead, la interfaz AEAD de la API criptográfica de usuario AF_ALG. Según CERT-EU, la vulnerabilidad tiene una puntuación CVSS de 7,8 y procede de una optimización introducida en 2017 que permitió colocar páginas de la page cache en una lista de destino escribible. En la práctica, esa combinación abre la puerta a una escritura controlada en memoria sobre datos que deberían permanecer protegidos.
Un fallo local, pero con impacto amplio
Copy Fail no necesita acceso de red ni una configuración específica para cada distribución. Requiere una cuenta local sin privilegios y un kernel vulnerable. Ese matiz es importante: no convierte automáticamente cualquier servidor expuesto a internet en una víctima directa, pero sí agrava mucho cualquier compromiso inicial. Si un atacante consigue acceso limitado a una cuenta, a un contenedor mal aislado o a un entorno de ejecución compartido, la vulnerabilidad puede servir para saltar a privilegios de administrador.
El equipo de Xint Code y Theori, que publicó el análisis técnico, afirma que el fallo afecta a kernels construidos desde 2017 hasta la incorporación del parche, lo que incluye muchas distribuciones Linux ampliamente desplegadas. La vulnerabilidad se hizo pública con una prueba de concepto muy pequeña, lo que ha acelerado la presión sobre fabricantes y equipos de operaciones.
El mecanismo es especialmente delicado porque no modifica directamente el archivo en disco. La explotación se basa en corromper la representación en memoria de un binario legible a través de la page cache del kernel. Esto complica la detección mediante herramientas tradicionales que comparan hashes o integridad en disco, ya que el fichero persistente no tiene por qué quedar alterado.
| Aspecto | Detalle |
|---|---|
| Identificador | CVE-2026-31431 |
| Nombre común | Copy Fail |
| Tipo | Escalada local de privilegios |
| Componente afectado | Kernel Linux, algif_aead / AF_ALG |
| Origen técnico | Optimización introducida en 2017 |
| Requisito para explotar | Usuario local sin privilegios |
| Riesgo principal | Obtención de privilegios root |
| Severidad publicada | CVSS 7,8 |
| Mitigación recomendada | Actualizar kernel y reiniciar |
Por qué preocupa en servidores, contenedores y CI/CD
La gravedad de Copy Fail está menos en su sofisticación visible y más en dónde puede aparecer. En un portátil personal con un solo usuario, el riesgo depende de que alguien ya pueda ejecutar código localmente. En un servidor compartido, en cambio, el panorama cambia. Un proveedor de hosting, una máquina de desarrollo con varios usuarios, un sistema universitario, una plataforma de integración continua o un nodo que ejecuta cargas de terceros pueden tener usuarios o procesos no confiables conviviendo en la misma máquina.
También afecta al mundo de los contenedores. Un contenedor no es una máquina virtual completa; comparte kernel con el host. Si la política de aislamiento permite acceder a la interfaz afectada o no restringe adecuadamente determinadas llamadas, un fallo local del kernel puede convertirse en un problema de escape o escalada. Por eso varias recomendaciones se centran no solo en actualizar el kernel, sino también en endurecer perfiles seccomp, AppArmor o SELinux.
La Universidad de Toronto, por ejemplo, recomienda parchear de inmediato, reiniciar para cargar el nuevo kernel y endurecer nodos Kubernetes o contenedores, restringiendo cargas no confiables que puedan abrir sockets AF_ALG. OVHcloud también ha publicado recomendaciones específicas para proteger clústeres Kubernetes gestionados frente a este fallo.
La situación es más compleja porque las mitigaciones no son idénticas en todas las distribuciones. En algunos sistemas, algif_aead puede estar disponible como módulo y bloquear su carga puede reducir el riesgo. En otros, como varias distribuciones de la familia RHEL, esa funcionalidad puede estar compilada dentro del kernel, por lo que un bloqueo mediante modprobe.d no resulta efectivo. CloudLinux ha advertido expresamente de este punto y recomienda usar los métodos indicados por su propio advisory hasta que el kernel parcheado o el livepatch estén disponibles.
Qué deben hacer los administradores
La prioridad es clara: aplicar el kernel corregido de la distribución correspondiente y reiniciar. En Linux, instalar el paquete no basta si el sistema sigue ejecutando el kernel vulnerable cargado en memoria. En entornos donde no sea posible reiniciar de inmediato, las soluciones de livepatch del proveedor pueden reducir la ventana de exposición, siempre que cubran esta CVE concreta.
También conviene revisar qué usuarios pueden ejecutar código local, qué cargas se aceptan en contenedores, qué jobs de CI/CD proceden de fuentes no confiables y qué máquinas permiten shell a terceros. Copy Fail no sustituye a una vulnerabilidad remota inicial, pero convierte un acceso limitado en algo mucho más peligroso.
La segunda medida es verificar el estado real de los sistemas. No basta con asumir que una distribución ya ha publicado parche. Hay que comprobar la versión de kernel en ejecución, revisar boletines del proveedor y confirmar si el equipo ha arrancado con el kernel actualizado. En flotas grandes, esto debería integrarse en inventario, gestión de vulnerabilidades y herramientas de configuración.
La tercera recomendación es tratar las mitigaciones genéricas con cautela. Algunos consejos que circulan por internet pueden funcionar en determinadas distribuciones y no en otras. El caso del bloqueo de algif_aead mediante modprobe.d es un buen ejemplo: puede servir si la funcionalidad se carga como módulo, pero puede dar una falsa sensación de seguridad si está compilada dentro del kernel.
Para equipos de seguridad, Copy Fail también recuerda una lección más amplia: la frontera entre “vulnerabilidad local” y “riesgo crítico” se ha vuelto más fina. La nube, los contenedores, los runners CI/CD, los servidores compartidos y los entornos de desarrollo remoto multiplican los escenarios donde un usuario no privilegiado puede existir legítimamente dentro de una máquina. En esos casos, una escalada local a root puede ser el paso que convierte una intrusión limitada en compromiso completo.
El parche ya está en el kernel principal y los proveedores están publicando actualizaciones, pero la velocidad de despliegue será desigual. Algunas distribuciones tendrán paquetes listos antes que otras; algunos entornos aplicarán livepatch; otros esperarán ventanas de mantenimiento. Esa diferencia de tiempos es justo lo que los atacantes intentan aprovechar cuando una prueba de concepto ya es pública.
Copy Fail no exige pánico, pero sí reacción. Los administradores deberían priorizar servidores multiusuario, hosts de contenedores, plataformas CI/CD, sistemas de hosting, entornos académicos, máquinas con usuarios externos y cualquier infraestructura donde una cuenta limitada no pueda considerarse plenamente confiable. En un fallo de escalada local, el tiempo entre “usuario sin privilegios” y “root” es la parte que más importa.
Preguntas frecuentes
¿Qué es Copy Fail?
Copy Fail es el nombre de CVE-2026-31431, una vulnerabilidad del kernel Linux que permite a un usuario local sin privilegios escalar a root en sistemas afectados.
¿Puede explotarse desde internet sin acceso previo?
No es una vulnerabilidad remota directa. El atacante necesita ejecutar código como usuario local o dentro de un entorno donde pueda interactuar con el kernel vulnerable.
¿Afecta a contenedores y Kubernetes?
Puede afectar a hosts que ejecutan contenedores si el kernel es vulnerable y las políticas de aislamiento no restringen adecuadamente el acceso a las interfaces implicadas. Por eso se recomienda parchear nodos y revisar perfiles seccomp, AppArmor o SELinux.
¿Cuál es la mitigación principal?
Actualizar el kernel con el parche de la distribución y reiniciar. Las mitigaciones temporales deben aplicarse siguiendo las instrucciones del proveedor, porque no todas funcionan igual en todas las distribuciones.
