Ir al contenido
EuroVPSEuroVPS

CVE-2026-31431 «Copy Fail»: fallo del kernel Linux, fix

FAQ de EuroVPS

Actualizado el 9 min de lectura

Shared FAQ page chrome (breadcrumb, dates, read time, «Siga leyendo», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Resumen

Se ha divulgado públicamente una vulnerabilidad de escalada local de privilegios de alto impacto en el kernel Linux, CVE-2026-31431, conocida también como «Copy Fail».

La vulnerabilidad afecta a la interfaz criptográfica del kernel Linux, en concreto a la ruta algif_aead / AF_ALG. En las versiones de kernel afectadas, un usuario local sin privilegios puede escalar privilegios hasta root. Los investigadores originales describen el problema como presente en las distribuciones Linux mayoritarias con kernels compilados desde 2017, con especial riesgo para servidores multiusuario, plataformas de contenedores, runners de CI/CD y entornos multiinquilino.

El problema se registra como CVE-2026-31431. Ubuntu lo califica como High con CVSS 7.8, mientras que Red Hat califica el impacto como Important.

EuroVPS recomienda encarecidamente revisar y parchear todos los servidores Linux afectados en cuanto los fabricantes publiquen kernels corregidos o mitigaciones.


Qué es CVE-2026-31431

CVE-2026-31431 es una vulnerabilidad del kernel Linux en el subsistema crypto. El fallo está relacionado con una operación in-place incorrecta en algif_aead, cuando los mapeos de origen y destino difieren. La corrección upstream del kernel se asocia al commit mainline a664bf3d603d, que revierte la optimización problemática de 2017.

La vulnerabilidad no es por sí misma una vulnerabilidad remota de red. Sin embargo, si un atacante ya dispone de acceso local a shell, de acceso a través de una aplicación web comprometida, de ejecución en un contenedor o de cualquier otro punto de apoyo, puede permitirle escalar hasta privilegios completos de root.


Sistemas operativos afectados y correcciones / parches de los fabricantes

La vulnerabilidad puede afectar a muchas distribuciones Linux con kernels compilados desde 2017. El estado varía según la distribución y la rama de kernel, así que la acción correcta es seguir el aviso oficial del fabricante de su sistema operativo.

1. AlmaLinux

AlmaLinux ha publicado kernels corregidos para las versiones con soporte. Las versiones corregidas confirmadas son:

SistemaVersión de kernel corregida
AlmaLinux 8kernel-4.18.0-553.121.1.el8_10 or newer
AlmaLinux 9kernel-5.14.0-611.49.2.el9_7 or newer
AlmaLinux 10kernel-6.12.0-124.52.2.el10_1 or newer
AlmaLinux Kitten 10kernel-6.12.0-225.el10 or newer

Actualización recomendada:

sudo dnf clean all
sudo dnf upgrade 'kernel*'
sudo reboot

Verifique tras el reinicio:

uname -r
rpm -q kernel

2. Oracle Linux

Oracle Linux también está afectado cuando ejecuta compilaciones vulnerables del kernel Linux. Oracle ha publicado actualizaciones de seguridad del Unbreakable Enterprise Kernel (UEK) para CVE-2026-31431 bajo las erratas oficiales de Oracle Linux.

Versión de Oracle Linux / rama de kernelKernel corregido / nivel de parche
Oracle Linux 7 / 8, UEK R6kernel-uek-5.4.17-2136.354.4.2.el7uek / el8uek or newer
Oracle Linux 8 / 9, UEK R7kernel-uek-5.15.0-319.201.4.4.el8uek / el9uek or newer
Oracle Linux 9 / 10, UEK R8kernel-uek-6.12.0-201.74.2.2.el9uek / el10uek or newer

Oracle clasifica las actualizaciones UEK como SECURITY, IMPORTANT, publicadas el 2026-05-01, e incluye CVE-2026-31431 entre las correcciones crypto del kernel.

Actualización recomendada:

sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot

En sistemas Oracle Linux antiguos que usan yum:

yum clean all
yum update 'kernel*'
reboot

Verificación en Oracle Linux

cat /etc/oracle-release
uname -r
rpm -q kernel-uek
rpm -q kernel kernel-core

Asegúrese de que el kernel en ejecución que muestra uname -r es el kernel corregido, no solo que esté instalado.

3. CloudLinux

CloudLinux confirma que CL7 no está afectado, mientras que CL7h, CL8, CL9 y CL10 sí lo están. CL7h y CL8 se parchean mediante kernels de CloudLinux, mientras que CL9 y CL10 usan las actualizaciones de kernel de AlmaLinux.

Las versiones objetivo confirmadas de CloudLinux incluyen:

SistemaVersión de kernel corregida
CloudLinux 7Not affected
CloudLinux 7 Hybrid / CL7hkernel-4.18.0-553.121.1.lve.el7h.x86_64 or newer
CloudLinux 8kernel-4.18.0-553.121.1.lve.el8.x86_64 or newer
CloudLinux 9kernel-5.14.0-611.49.2.el9_7 or newer
CloudLinux 10kernel-6.12.0-124.52.2.el10_1 or newer

Actualización recomendada para CloudLinux 8 / 9 / 10:

sudo dnf clean metadata
sudo dnf upgrade 'kernel*'
sudo reboot

En sistemas CloudLinux antiguos que usan yum:

yum update 'kernel*'
reboot

Verifique:

uname -r
rpm -q kernel

En sistemas con KernelCare:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

CloudLinux indica que los live patches de KernelCare para muchas distribuciones afectadas, incluidas las ramas de AlmaLinux, CloudLinux, Red Hat, Rocky, Oracle Linux, Ubuntu y Debian, se publicaron en el feed principal el 2 de mayo de 2026.


4. Ubuntu

Ubuntu ha publicado un registro en su tracker de CVE y una entrada de blog dedicada a este problema. Ubuntu indica que la mitigación se distribuye a través del paquete kmod y que la corrección de la vulnerabilidad se distribuirá a través de los paquetes de imagen del kernel Linux.

Actualización recomendada:

sudo apt update
sudo apt upgrade
sudo reboot

Para aplicar únicamente el paquete de mitigación donde proceda:

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Verificación:

uname -r
dpkg -l 'linux-image*' | grep ^ii
dpkg -l kmod

Para comprobar si el módulo afectado está cargado actualmente:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Ubuntu documenta también una mitigación manual con una regla modprobe.d y la descarga de algif_aead, pero este enfoque no es adecuado para todas las distribuciones, especialmente para los sistemas de la familia RHEL, donde la funcionalidad puede estar compilada dentro del kernel.


5. Debian

El tracker de seguridad de Debian lista las versiones corregidas para varias versiones de Debian:

Versión de DebianVersión corregida
Bullseye security5.10.251-3
Bookworm security6.1.170-1
Trixie security6.12.85-1
Forky6.19.14-1
Sid7.0.3-1

Actualización recomendada:

sudo apt update
sudo apt upgrade
sudo reboot

Verifique:

uname -r
dpkg -l 'linux-image*' | grep ^ii

6. Red Hat Enterprise Linux

Red Hat ha publicado un boletín de seguridad y una página de CVE para CVE-2026-31431. Red Hat lo describe como un problema de la interfaz criptográfica del kernel Linux por el que un usuario local puede obtener privilegios de root. Red Hat califica el problema como Important e indica que las correcciones se publican a través de los canales correspondientes de Red Hat.

Acción recomendada:

sudo dnf update 'kernel*'
sudo reboot

Verifique:

uname -r
rpm -q kernel
rpm -q kernel-core

En sistemas con suscripción de Red Hat, consulte también la página oficial del CVE y los avisos de Red Hat para conocer el paquete corregido exacto de su versión de RHEL y rama de kernel.


7. SUSE

SUSE califica CVE-2026-31431 como important y sigue su estado por producto y paquete. Algunos paquetes de SUSE 15 SP7 figuran como publicados, mientras que varias ramas de SUSE 16 y SUSE Linux Micro seguían listadas como afectadas o en curso en la página de CVE de SUSE en el momento de la revisión.

Acción recomendada:

sudo zypper refresh
sudo zypper update
sudo reboot

Verifique:

uname -r
rpm -q kernel-default

Consulte la página de CVE de SUSE para conocer el estado exacto del paquete de su producto, service pack y variante de kernel.


Mitigación temporal si no puede actualizar de inmediato

En sistemas Oracle Linux / AlmaLinux / CloudLinux / familia RHEL

En sistemas de la familia RHEL, la mitigación temporal más segura es poner en lista negra el initcall algif_aead_init mediante la línea de comandos del kernel y reiniciar:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Verifique tras el reinicio:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

o:

sudo grubby --info=ALL | grep initcall_blacklist

CloudLinux advierte específicamente de que la mitigación habitual con modprobe.d puede no funcionar en CloudLinux, AlmaLinux u otros sistemas de la familia RHEL, porque algif_aead puede estar compilado dentro del kernel. En ese caso, rmmod y las reglas modprobe.d pueden dar una falsa sensación de protección.

Tras instalar un kernel corregido, puede retirar la mitigación temporal:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

En sistemas Ubuntu / Debian

Ubuntu documenta la siguiente mitigación donde proceda:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null

Verifique:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Puede ser necesario reiniciar si el módulo no se puede descargar de forma segura.


Bastionado de contenedores y Kubernetes

En entornos de contenedores, parchear el kernel del host sigue siendo la corrección principal. Sin embargo, se recomienda encarecidamente una contención adicional.

CERT-EU recomienda bloquear la creación de sockets AF_ALG mediante políticas seccomp en las cargas de trabajo en contenedores y en los pipelines de CI/CD. Docker documenta seccomp como una característica del kernel Linux que se usa para restringir las acciones de los contenedores, y el perfil seccomp por defecto de Docker sigue un modelo de lista de permitidos.

Comprobación de seccomp en Docker:

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

Resultado esperado:

CONFIG_SECCOMP=y

Ejecute los contenedores con el perfil seccomp por defecto salvo que exista un motivo concreto para no hacerlo:

docker run --security-opt seccomp=default.json ...

En Kubernetes, use RuntimeDefault o un perfil seccomp personalizado donde proceda. Kubernetes permite aplicar perfiles seccomp a Pods y contenedores, y su documentación explica cómo cargar y aplicar perfiles.

Ejemplo de contexto de seguridad en Kubernetes:

securityContext:
  seccompProfile:
    type: RuntimeDefault

Paso adicional para servidores LiteSpeed Enterprise

En servidores con LiteSpeed Enterprise, especialmente en entornos de hosting con CloudLinux / CageFS, EuroVPS recomienda aplicar el siguiente paso adicional de bastionado de LiteSpeed.

Se trata de un bastionado adicional para servidores con el binario lscgid de LiteSpeed; la actualización o mitigación del kernel descrita arriba sigue siendo necesaria.

LiteSpeed 6.3.5 figura en la documentación de LiteSpeed como una versión de seguridad, ajuste y corrección de errores, que incluye cambios relacionados con CloudLinux CageFS. La propia documentación de LiteSpeed muestra también que lscgid ha usado históricamente el permiso setuid en el funcionamiento normal de LiteSpeed/PHP.

Paso 2: bastionar el binario lscgid

Compruebe primero si LiteSpeed está instalado:

/usr/local/lsws/bin/lshttpd -v

Después elija una de las siguientes opciones.

Opción A: actualizar a LiteSpeed Enterprise 6.3.5 Build 5 o posterior (recomendada)

Esta es la opción preferida. La actualización de LiteSpeed aplica automáticamente el bastionado de permisos necesario en lscgid:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.5

Tras la actualización, reinicie LiteSpeed si es necesario:

/usr/local/lsws/bin/lswsctrl restart

Opción B: solución rápida si aún no puede actualizar

Si no puede actualizar LiteSpeed de inmediato, quite manualmente el permiso setuid del binario lscgid ahora:

chmod u-s /usr/local/lsws/bin/lscgid.*

Después reinicie LiteSpeed:

/usr/local/lsws/bin/lswsctrl restart

Lista de verificación

Ejecute las siguientes comprobaciones después de aplicar las actualizaciones o mitigaciones.

1. Identifique el sistema operativo y el kernel

cat /etc/os-release
uname -r

2. Compruebe los paquetes de kernel instalados

Sistemas basados en RPM:

rpm -q kernel
rpm -q kernel-core

Sistemas Debian/Ubuntu:

dpkg -l 'linux-image*' | grep ^ii

3. Confirme que el kernel en ejecución es el kernel corregido

Tras el reinicio:

uname -r

Compare la versión del kernel en ejecución con la versión corregida oficial del fabricante para su sistema operativo.

4. Confirme que la mitigación está activa, si la ha usado

En sistemas de la familia RHEL con la mitigación de grubby:

cat /proc/cmdline | grep initcall_blacklist=algif_aead_init

En la mitigación por módulo de Ubuntu/Debian:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

5. Verificación de KernelCare

kcarectl --update
kcarectl --info | grep CVE-2026-31431

El CVE debería aparecer como parcheado en la salida de KernelCare donde exista un live patch.


Notas operativas importantes

No ejecute código público de prueba de concepto del exploit en servidores de producción.


Plan de acción recomendado por EuroVPS

EuroVPS recomienda el siguiente plan de acción:

  1. Más allá de parchear y reiniciar: aplique políticas seccomp a las cargas de trabajo en contenedores, retire los sistemas operativos en fin de vida y, en LiteSpeed Enterprise, actualice a 6.3.5 Build 5 o quite el bit setuid de lscgid.

¿Necesita ayuda?

Si desea que nuestros ingenieros comprueben, parcheen, mitiguen y verifiquen su servidor, abra un ticket de soporte desde el área de cliente con el hostname o la IP; comparta el acceso root únicamente a través del campo de credenciales seguras del ticket, nunca en el texto del ticket.

Enlaces oficiales de los fabricantes y referencias:

[1] Divulgación oficial de Copy Fail: https://copy.fail/ [2] Tracker de CVE de Ubuntu, CVE-2026-31431: https://ubuntu.com/security/CVE-2026-31431 [3] Blog de Ubuntu, correcciones disponibles para Copy Fail: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available [4] Aviso de AlmaLinux, CVE-2026-31431 Copy Fail: https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ [5] Blog de CloudLinux, actualización de kernel para CVE-2026-31431 Copy Fail: https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update [6] Página de incidente / estado de CloudLinux: https://cloudlinux.statuspage.io/incidents/642sgcmntkkk [7] Página de CVE de Red Hat, CVE-2026-31431: https://access.redhat.com/security/cve/CVE-2026-31431 [8] Boletín de seguridad de Red Hat: https://access.redhat.com/security/vulnerabilities/RHSB-2026-02 [9] Página de CVE de SUSE, CVE-2026-31431: https://www.suse.com/security/cve/CVE-2026-31431 [10] Tracker de seguridad de Debian, CVE-2026-31431: https://security-tracker.debian.org/tracker/CVE-2026-31431 [11] Documentación de seccomp de Docker: https://docs.docker.com/engine/security/seccomp/ [12] Documentación de seccomp de Kubernetes: https://kubernetes.io/docs/tutorials/security/seccomp/ [13] Oracle Linux 7 / 8, UEK R6: https://linux.oracle.com/errata/ELSA-2026-50255.html [14] Oracle Linux 8 / 9, UEK R7: https://linux.oracle.com/errata/ELSA-2026-50253.html [15] Oracle Linux 9 / 10, UEK R8: https://linux.oracle.com/errata/ELSA-2026-50254.html

De las FAQ de EuroVPS, publicado por primera vez el 3 de mayo de 2026.

Más en la categoría «Anuncios»

Su próximo socio de infraestructura

¿Todavía tiene
una pregunta?

Díganos qué intenta hacer. Un ingeniero lo leerá y le responderá.

+357 222 32280
Un ingeniero de EuroVPS transporta un nodo de servidor en la sala del datacenter
Una conversación con las personas que cuidarán de su infraestructura.

Empecemos por su infraestructura.

Un poco de contexto nos ayuda a empezar la conversación adecuada.

Usaremos sus datos para responder a su consulta. Política de privacidad