CVE-13413-6202 – Vulnerabilidad crítica en Linux

El 29 de abril de 2026 se hizo pública CVE-13413-6202, conocida como Copy Fail, una vulnerabilidad de escalada local de privilegios en el kernel de Linux. El fallo afecta al subsistema criptográfico del kernel, concretamente a la interfaz algif_aead, utilizada a través de la API criptográfica de espacio de usuario AF_ALG. CERT-EU la ha clasificado como una vulnerabilidad de severidad alta, con una puntuación CVSS de 7.8.

Aunque no es una vulnerabilidad explotable directamente desde Internet, su impacto es importante: un usuario local sin privilegios puede llegar a obtener permisos de root en un sistema vulnerable. Esto la convierte en un riesgo especialmente serio para servidores compartidos, nodos de Kubernetes, entornos de CI/CD, plataformas multiusuario y sistemas donde se ejecuten cargas de trabajo de terceros.

Qué hace realmente Copy Fail

La vulnerabilidad permite que un proceso sin privilegios modifique la page cache del kernel. La page cache es la copia en memoria que Linux mantiene de determinados archivos para acelerar las lecturas.

Lo delicado del fallo es que la modificación no se realiza sobre el archivo físico en disco, sino sobre su representación en memoria. Es decir, el archivo original puede seguir intacto, pero los procesos que lean desde la caché pueden ver una versión alterada.

Tenable resume el impacto de forma muy clara: el fallo permite a un usuario local modificar la copia cacheada de un archivo en memoria sin cambiar el archivo en disco; si el objetivo es un binario privilegiado, el atacante puede obtener acceso root.

Esto complica la detección, porque una comprobación tradicional de integridad sobre disco puede no mostrar cambios. El binario real no tiene por qué estar alterado, pero su versión cargada en memoria sí puede estarlo.

Por qué es tan peligrosa

Copy Fail no es una vulnerabilidad remota clásica. No permite, por sí sola, entrar desde fuera a un servidor expuesto en Internet. Sin embargo, una vez que alguien tiene ejecución local, aunque sea con un usuario limitado, la vulnerabilidad puede permitir elevar privilegios hasta root.

Esto es especialmente grave en varios escenarios:

En servidores con varios usuarios, porque cualquier cuenta local comprometida podría convertirse en una vía hacia privilegios administrativos.

En entornos de hosting, porque diferentes clientes o procesos pueden compartir el mismo kernel.

En Kubernetes y plataformas de contenedores, porque los contenedores comparten el kernel del host. CERT-EU recomienda priorizar expresamente nodos Kubernetes y runners de CI/CD expuestos a cargas no confiables.

En pipelines de integración continua, porque muchos sistemas ejecutan código externo o de ramas no verificadas.

En servidores donde existan procesos web vulnerables, porque una intrusión inicial con permisos bajos podría terminar en compromiso total del sistema.

El punto clave es este: Copy Fail convierte una intrusión limitada en una posible toma completa del servidor.

Qué sistemas pueden estar afectados

El fallo se introdujo por una optimización del kernel incluida en 2017, identificada con el commit 72548b093ee3. Esa optimización permitía operaciones “in-place” en algif_aead, pero acabó permitiendo que páginas de la page cache entrasen en listas de destino escribibles.

Según CERT-EU, la vulnerabilidad afecta a distribuciones Linux principales que hayan distribuido kernels construidos desde 2017 hasta la disponibilidad del parche. Entre las distribuciones verificadas por los investigadores se mencionan Ubuntu, Amazon Linux, RHEL y SUSE, además de otras distribuciones potencialmente afectadas como Debian, Fedora, Arch, Rocky Linux, AlmaLinux u Oracle Linux.

Debian, por ejemplo, muestra en su tracker que determinadas ramas seguían vulnerables mientras que otras ya tenían versiones corregidas, como trixie-security con 6.12.85-1, forky y sid.

Por tanto, no basta con saber la distribución. Hay que comprobar la versión exacta del kernel y el estado del parche del proveedor.

Cómo comprobar la versión del kernel

En cualquier servidor Linux, el primer paso es revisar la versión activa del kernel:

uname -a

O de forma más concreta:

uname -r

Después conviene consultar el boletín de seguridad de la distribución correspondiente. No todas las distribuciones publican el parche al mismo tiempo, y algunas pueden backportar la corrección sin cambiar aparentemente a una versión mayor del kernel.

También es recomendable listar los paquetes de kernel instalados:

Debian / Ubuntu

dpkg -l | grep linux-image

RHEL / Rocky / AlmaLinux / Oracle Linux

rpm -qa | grep kernel

SUSE

rpm -qa | grep kernel

Cómo parchear servidores Linux

La solución correcta es aplicar el kernel corregido publicado por la distribución y reiniciar el servidor para arrancar con la versión parcheada.

Debian / Ubuntu

sudo apt update
sudo apt upgrade
sudo reboot

Después del reinicio:

uname -r

Y, si se quiere confirmar si todavía hay reinicio pendiente:

test -f /var/run/reboot-required && cat /var/run/reboot-required

En servidores Ubuntu con needrestart instalado:

sudo needrestart

RHEL / Rocky Linux / AlmaLinux / Oracle Linux

sudo dnf update kernel
sudo reboot

En versiones antiguas:

sudo yum update kernel
sudo reboot

Después:

uname -r

SUSE / openSUSE

sudo zypper refresh
sudo zypper update kernel-default
sudo reboot

Después:

uname -r

Amazon Linux

sudo dnf update kernel
sudo reboot

O, en sistemas basados en Amazon Linux 2:

sudo yum update kernel
sudo reboot

Después:

uname -r

Mitigación temporal si todavía no hay parche

Si el proveedor todavía no ha publicado kernel corregido, CERT-EU recomienda deshabilitar temporalmente el módulo algif_aead en sistemas afectados. La mitigación propuesta es:

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

Esta medida intenta impedir que el módulo vulnerable pueda cargarse. No obstante, debe probarse antes en entornos críticos, porque puede afectar a aplicaciones que usen explícitamente la interfaz AF_ALG.

CERT-EU indica que esta mitigación no debería afectar a componentes habituales como dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS o SSH, aunque sí podría afectar a aplicaciones que usen directamente sockets AF_ALG.

Para revisar posibles usos de AF_ALG:

sudo lsof | grep AF_ALG

Mitigación en contenedores y Kubernetes

En entornos con contenedores, la prioridad debe ser mayor. Aunque el contenedor tenga permisos limitados, comparte kernel con el host. Si el exploit consigue abusar de una funcionalidad del kernel, el impacto puede superar el aislamiento esperado.

CERT-EU recomienda bloquear la creación de sockets AF_ALG mediante políticas seccomp en cargas contenerizadas y pipelines, incluso aunque el sistema esté pendiente de parche.

En Kubernetes, esto implica revisar:

securityContext
seccompProfile
privileged
allowPrivilegeEscalation
capabilities
hostPID
hostIPC
hostNetwork

Como regla general, mientras se parchea:

securityContext:
  allowPrivilegeEscalation: false
  privileged: false
  seccompProfile:
    type: RuntimeDefault

Esto no sustituye el parche del kernel, pero reduce superficie de ataque.

Orden recomendado de actuación

Para una empresa con varios servidores, el orden lógico sería:

1. Inventariar kernels activos con uname -r.
2. Priorizar servidores multiusuario, Kubernetes, Docker hosts y CI/CD runners.
3. Aplicar actualizaciones de kernel desde los repositorios oficiales.
4. Reiniciar para cargar el kernel corregido.
5. Verificar versión activa tras el reinicio.
6. Aplicar mitigación temporal si aún no hay kernel disponible.
7. Revisar uso de AF_ALG si se va a deshabilitar algif_aead.
8. Endurecer contenedores con seccomp, sin privilegios y sin capacidades innecesarias.
9. Monitorizar accesos locales sospechosos, ejecución de scripts no autorizados y cambios anómalos en procesos privilegiados.

Comandos rápidos de comprobación

Versión del kernel:

uname -r

Fecha de arranque del kernel actual:

uptime -s

Paquetes de kernel instalados en Debian/Ubuntu:

dpkg -l | grep linux-image

Paquetes de kernel instalados en RHEL/SUSE/Amazon Linux:

rpm -qa | grep kernel

Comprobar si el módulo está cargado:

lsmod | grep algif_aead

Bloquear carga del módulo como mitigación temporal:

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

Conclusión

CVE-13413-6202, conocida como Copy Fail, es una vulnerabilidad importante porque afecta a una pieza central del sistema: el kernel de Linux. Su explotación requiere acceso local, pero una vez conseguido ese punto inicial puede permitir escalar a root de forma fiable en sistemas vulnerables.

El riesgo es especialmente alto en servidores compartidos, plataformas cloud, contenedores, Kubernetes y entornos de CI/CD. La recomendación principal es aplicar cuanto antes el kernel corregido de cada distribución y reiniciar los sistemas afectados. Mientras el parche no esté disponible, se debe valorar la mitigación temporal sobre algif_aead y reforzar las políticas de aislamiento en contenedores.