Copy Fail: cómo explotan la vulnerabilidad crítica del kernel Linux CVE-2026-31431

Introducción

El martes 29 de abril de 2026 se hizo pública Copy Fail (CVE-2026-31431), una vulnerabilidad crítica en el kernel Linux que permite a un atacante con privilegios mínimos obtener una shell con permisos de root. A diferencia de fallos que requieren acceso previo como usuario, este funciona en entornos donde solo hay ejecución de código no privilegiado, como contenedores, pipelines de CI/CD o servicios en la nube compartidos. Microsoft ya reportó explotación limitada in-the-wild, pero el impacto potencial es alto: desde breakout de contenedores hasta movimiento lateral en clusters Kubernetes.

El problema reside en el módulo AEAD del kernel (implementado en versiones desde Linux 5.10 hasta 6.8), específicamente en cómo maneja el caché de páginas de binarios con setuid-root. Un atacante puede modificar esa caché en memoria para sobrescribir el contenido de programas con permisos elevados, logrando ejecución de código arbitrario como root. La explotación es silenciosa: no deja huella en disco, solo modifica memoria volátil.

Qué ocurrió

El 29 de abril de 2024, el equipo de seguridad de Microsoft reportó el hallazgo de Copy Fail a los mantenedores del kernel. El CVE fue asignado el 15 de mayo de 2024 y publicado oficialmente el 29 de abril de 2026 (sí, dos años después de su descubrimiento). Según el aviso de CISA, el fallo afecta a todas las distribuciones Linux desde 2017 (kernel 4.4+) con la plantilla AEAD activada.

Microsoft detalló que la explotación comienza con un usuario local no privilegiado que ejecuta un script malicioso. Este script identifica binarios setuid-root en memoria (como /usr/bin/sudo o /usr/bin/passwd) y modifica su caché de páginas para inyectar código arbitrario. El ataque es reproducible en menos de 100 líneas de código y ya existe un proof-of-concept (PoC) público en GitHub. Aunque CISA no especificó casos reales de explotación masiva, Microsoft advirtió que el PoC acelera la creación de exploits automatizados, especialmente en entornos cloud y Kubernetes.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y CI/CD

En pipelines de CI/CD, Copy Fail es un riesgo crítico: un atacante con acceso a un job malicioso puede escalar a root y comprometer todo el proceso de construcción. Según datos de Microsoft, el 35% de los clusters Kubernetes en entornos híbridos usan kernels vulnerables (versiones 5.15 a 6.5). La explotación requiere solo que el pod tenga permisos para ejecutar mount o modificar /proc/self/mem.

Infraestructura y Cloud

En entornos cloud como EKS (Amazon), GKE (Google) o AKS (Azure), el riesgo es aún mayor: un atacante en un namespace compartido puede romper el aislamiento de contenedores y acceder a recursos de otros tenants. Microsoft destacó que el 78% de los ataques a contenedores en 2025 involucraron escalada de privilegios, y CVE-2026-31431 es una herramienta ideal para ello. Además, el vector de ataque en memoria dificulta su detección con herramientas tradicionales de host-based intrusion detection (HIDS).

Seguridad

El CVSS score asignado al CVE es 9.8 (Crítico), con impacto en confidencialidad, integridad y disponibilidad. La explotación no requiere interacción del usuario y puede combinarse con otras técnicas como SSH pivoting o compromiso de CI jobs. Según el aviso de CISA, el plazo para parchear en agencias federales es 14 días desde el 10 de mayo de 2026, pero en entornos privados el riesgo persiste hasta que se aplique el parche.

Detalles técnicos

Componente afectado

El fallo reside en el subsistema AEAD (Authenticated Encryption with Associated Data) del kernel Linux, específicamente en la función crypto_aead_encrypt(). Esta función es usada por módulos como dm-crypt (para cifrado de discos) y af_alg (API de criptografía para usuarios). La vulnerabilidad permite a un atacante con acceso local sobrescribir la caché de páginas de binarios setuid-root en memoria.

Versiones afectadas

1. Reconocimiento: El atacante identifica un binario setuid-root en memoria (ej: /usr/bin/sudo).
2. Explotación: Ejecuta un script que:

– Sobrescribe el código del binario en la caché de páginas.

– Provoca un return-oriented programming (ROP) para ejecutar shellcode como root.

1. Evasión: La modificación es en memoria, por lo que no hay cambios en disco y pasa desapercibida para herramientas de escaneo como Tripwire o AIDE.

Ejemplo de PoC (simplificado)

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

void exploit() {
    int fd = open("/proc/self/mem", O_RDWR);
    // Buscar la dirección del binario setuid en memoria
    void *target = mmap(..., PROT_READ | PROT_WRITE);
    // Sobrescribir el código en memoria
    lseek(fd, (off_t)target, SEEK_SET);
    char shellcode[] = "\x31\xc0\x48\xbb\xd1..."; // /bin/sh shellcode
    write(fd, shellcode, sizeof(shellcode));
    // Ejecutar el binario modificado
    execl("/usr/bin/sudo", "sudo", NULL);
}

Microsoft destacó que este PoC es solo un ejemplo; los exploits reales usan técnicas de heap spraying para maximizar la probabilidad de éxito.

Entornos críticos afectados

• Kubernetes: Clusters con nodos usando kernels 5.15 a 6.5 son explotables si un pod tiene permisos para ejecutar mount o modificar /proc.
• Cloud: Proveedores como AWS, GCP y Azure ya actualizaron sus imágenes base, pero miles de instancias siguen sin parchear.
• CI/CD: Pipelines con runners en contenedores vulnerables (ej: GitHub Actions con imágenes Ubuntu 22.04 sin parches).

Qué deberían hacer los administradores y equipos técnicos

1. Identificar sistemas vulnerables

Ejecuten este comando para listar kernels afectados en servidores Linux:

uname -r | grep -E "4\.4|4\.19|5\.[4-9]|5\.1[0-9]|6\.[0-5]"

Si el resultado incluye versiones como 5.15.0-105-generic o 6.2.0-39-generic, el sistema está en riesgo.

2. Parchear con urgencia

Apliquen los siguientes parches según su distribución:

3. Aislar entornos críticos

• Contenedores: Apliquen Pod Security Admission en Kubernetes para bloquear pods con permisos elevados:

  apiVersion: v1
  kind: Namespace
  metadata:
    name: secure-ns
    labels:
      pod-security.kubernetes.io/enforce: "restricted"
  

• CI/CD: Actualicen las imágenes base de runners a versiones parcheadas (ej: ubuntu:24.04).

4. Monitorear actividad sospechosa

Configuren reglas en herramientas como Falco o Sysdig para detectar:

• Modificaciones en /proc/self/mem.
• Ejecución de binarios setuid desde procesos no autorizados.
• Llamadas a mmap con permisos PROT_WRITE | PROT_EXEC.

Ejemplo de regla Falco:

- rule: SetuidRootModification
  desc: "Detecta modificación de binarios setuid-root en memoria"
  condition: >
    spawned_process and
    user.name != "root" and
    (fd.name = "/proc/*/mem" or fd.name = "/dev/shm/*")
  output: >
    "Posible explotación de Copy Fail: %user.name modifica memoria de binarios setuid"
  priority: CRITICAL

5. Revisar logs de explotación

Busquen patrones como:

• Accesos a /proc/self/mem desde usuarios no root.
• Ejecución de chmod +x en binarios del sistema.
• Llamadas a execve desde procesos no autorizados.

Conclusión

La prioridad es parchear en 72 horas, especialmente en entornos con múltiples tenants o CI/CD compartido. Si no pueden actualizar kernels inmediatamente, apliquen mitigaciones como:

• Deshabilitar módulos AEAD no usados: sudo modprobe -r af_alg dm-crypt.
• Aplicar SELinux/AppArmor en modo enforcing.
• Restringir permisos de usuarios en /proc/self/mem con capsh.

El tiempo de ventana de ataque es mínimo, pero el impacto es máximo. No esperen a que un exploit automático aparezca en la dark web: actúen ahora.