CloudLinux ha alertado de una nueva vulnerabilidad del kernel Linux, identificada como CVE-2026-31431 y conocida como “Copy Fail”, que afecta a CloudLinux 7h, 8, 9 y 10. La compañía advierte de que un usuario local sin privilegios puede escalar permisos hasta root si el sistema es vulnerable y no se aplica una mitigación o un kernel corregido.
El aviso es especialmente relevante para proveedores de hosting, administradores de servidores compartidos, entornos con múltiples usuarios locales y plataformas donde conviven cuentas de clientes en el mismo sistema. CloudLinux 7 no está afectado, pero CloudLinux 7h, CloudLinux 8, CloudLinux 9 y CloudLinux 10 sí entran en el perímetro de riesgo. La empresa trabaja en kernels parcheados y livepatches de KernelCare, pero recomienda aplicar una mitigación temporal mientras llegan las actualizaciones definitivas.
Qué es CVE-2026-31431 y por qué preocupa
Copy Fail es una vulnerabilidad de escalada local de privilegios en el componente algif_aead, relacionado con la interfaz criptográfica AF_ALG del kernel Linux. Dicho de forma sencilla, el fallo puede permitir que un usuario ya autenticado en el sistema manipule memoria del kernel de forma que acabe obteniendo privilegios de administrador.
No es una vulnerabilidad remota que permita entrar directamente desde internet sin credenciales, pero eso no la hace menor. En servidores multiusuario, paneles de hosting, entornos con cuentas SSH, contenedores, tareas programadas o aplicaciones comprometidas, un atacante que ya haya logrado acceso limitado puede usar una vulnerabilidad local para tomar el control completo del sistema.
El caso preocupa también porque el problema afecta a kernels Linux publicados durante años y porque ya existe información técnica pública suficiente para que los administradores deban tratarlo como una prioridad. CERT-EU ha calificado la vulnerabilidad como de alta severidad, con una puntuación CVSS 7.8, y la base NVD recoge el fallo en el subsistema criptográfico del kernel.
En CloudLinux, el impacto queda repartido según versión. CloudLinux 7 no está afectado. CloudLinux 7h y CloudLinux 8 recibirán kernels corregidos de CloudLinux. CloudLinux 9 y 10 dependen del kernel de AlmaLinux, por lo que el parche llegará por esa vía. KernelCare ofrecerá livepatch para las versiones afectadas, lo que permitirá corregir sin reinicio en sistemas suscritos una vez publicada la actualización correspondiente.
| Versión | Estado | Vía prevista de corrección |
|---|---|---|
| CloudLinux 7 | No afectada | No requiere parche por este CVE |
| CloudLinux 7h | Afectada | Kernel CloudLinux y KernelCare |
| CloudLinux 8 | Afectada | Kernel CloudLinux y KernelCare |
| CloudLinux 9 | Afectada | Kernel AlmaLinux y KernelCare |
| CloudLinux 10 | Afectada | Kernel AlmaLinux y KernelCare |
La mitigación recomendada por CloudLinux
Hasta que estén disponibles los kernels definitivos o el livepatch de KernelCare, CloudLinux recomienda bloquear la inicialización de algif_aead mediante un parámetro del kernel gestionado con grubby. La mitigación requiere reiniciar el servidor, pero puede revertirse en pocos segundos una vez instalado el parche.
La instrucción recomendada por CloudLinux es:
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo rebootLenguaje del código: JavaScript (javascript)Después del reinicio, conviene verificar que el parámetro se ha aplicado:
sudo grubby --info=ALL | grep initcall_blacklistCuando el sistema ya tenga instalado un kernel corregido, la mitigación puede retirarse con:
sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo rebootLenguaje del código: JavaScript (javascript)La propia CloudLinux subraya un punto importante: una mitigación que circula en listas de seguridad basada en modprobe.d no funciona en CloudLinux, AlmaLinux ni en distribuciones de la familia RHEL cuando algif_aead está compilado dentro del kernel. En esos casos, añadir una regla como install algif_aead /bin/false puede dar una falsa sensación de seguridad, porque el módulo no se carga como módulo externo y no puede bloquearse de esa forma.
Este matiz es relevante para administradores que gestionan muchas máquinas. Aplicar una receta genérica copiada de otra distribución puede no proteger nada. En CloudLinux, la recomendación actual es usar el método con grubby hasta que el kernel o el livepatch estén disponibles.
Qué deben priorizar los administradores
La primera prioridad es identificar sistemas CloudLinux 7h, 8, 9 y 10 con usuarios locales o cargas multiusuario. En hosting compartido, servidores con acceso SSH para clientes, entornos con contenedores o máquinas donde varias aplicaciones ejecutan procesos con permisos separados, el riesgo operativo es mayor.
La segunda es decidir entre mitigación temporal y ventana de parcheo. Si KernelCare está desplegado, el administrador debe seguir el estado del livepatch y ejecutar el flujo habitual de actualización cuando esté disponible. Si no se dispone de livepatch, habrá que planificar la instalación del kernel corregido y el reinicio. Mientras tanto, CloudLinux recomienda aplicar la mitigación con grubby.
La tercera es revisar la exposición real. Aunque se trate de una escalada local, muchas intrusiones empiezan con una cuenta limitada, una aplicación web comprometida o un usuario con permisos bajos. Una vulnerabilidad local de root puede convertir ese primer acceso en control total del servidor.
También conviene revisar telemetría y registros. CloudLinux indica que Imunify360 ya detecta indicadores de compromiso publicados y utiliza heurísticas ampliadas para identificar señales nuevas. Aun así, la compañía insiste en que Imunify360 es una capa adicional de defensa, no un sustituto del parche del kernel.
| Acción recomendada | Objetivo |
|---|---|
| Identificar versiones CloudLinux afectadas | Priorizar sistemas 7h, 8, 9 y 10 |
Aplicar mitigación con grubby | Reducir superficie de ataque hasta el parche |
Evitar workaround con modprobe.d | No confiar en una mitigación que no aplica en RHEL-family |
| Monitorizar KernelCare y CloudLinux Status | Instalar livepatch o kernel corregido en cuanto esté disponible |
| Revisar accesos locales y registros | Detectar posibles intentos de explotación |
| Retirar la mitigación tras parchear | Mantener el sistema limpio una vez corregido |
Un aviso serio para proveedores de hosting
Copy Fail recuerda por qué el kernel sigue siendo una pieza crítica en cualquier servicio de alojamiento. Las capas de aislamiento, usuarios, jaulas, contenedores y políticas de seguridad reducen riesgos, pero una escalada local de privilegios puede romper buena parte de esa separación si no se corrige a tiempo.
Para proveedores de hosting, el problema no es solo técnico. También afecta a continuidad de servicio, confianza de clientes y capacidad de respuesta ante incidentes. Un reinicio masivo de servidores puede requerir coordinación, pero retrasar la mitigación en sistemas expuestos puede ser más arriesgado. La ventaja de KernelCare, cuando el livepatch esté disponible, será precisamente aplicar la corrección sin interrumpir el servicio.
CloudLinux ha indicado que los parches llegarán en un plazo corto, con tiempos distintos según producto. En CloudLinux 9 y 10, los kernels corregidos de AlmaLinux ya aparecen en repositorios de pruebas, aunque la recomendación para la mayoría de entornos de producción será esperar a la promoción estable salvo que el riesgo operativo obligue a actuar antes.
El mensaje para administradores es claro: no esperar a que el problema “se vea” en producción. Las vulnerabilidades locales suelen aprovecharse después de una primera brecha, y ahí el tiempo de reacción importa. La mitigación temporal es sencilla, pero exige reinicio; el parche definitivo será la solución correcta. Hasta entonces, cada servidor afectado debería estar inventariado, monitorizado y dentro de un plan de actuación.
Preguntas frecuentes
¿Qué es CVE-2026-31431 o Copy Fail?
Es una vulnerabilidad de escalada local de privilegios en el kernel Linux, relacionada con algif_aead y la interfaz criptográfica AF_ALG. Puede permitir que un usuario local sin privilegios obtenga acceso root.
¿Qué versiones de CloudLinux están afectadas?
CloudLinux 7h, 8, 9 y 10 están afectadas. CloudLinux 7 no lo está, según el aviso de CloudLinux.
¿Cuál es la mitigación temporal recomendada?
CloudLinux recomienda añadir initcall_blacklist=algif_aead_init al arranque del kernel mediante grubby y reiniciar el servidor hasta que esté disponible el kernel corregido o el livepatch de KernelCare.
¿Imunify360 sustituye al parche del kernel?
No. Imunify360 añade detección y mitigación frente a indicadores conocidos, pero CloudLinux recalca que no reemplaza la actualización del kernel o el livepatch.
vía: CloudLinux
