6 Min. tiempo de lectura
CISA ha incluido CVE-2026-31431 el 04.05.2026 en el catálogo de vulnerabilidades explotadas conocidas. CrowdStrike confirma la explotación activa en la naturaleza. Afectados: cualquier instancia de Linux con kernel desde 2017 y módulo AF_ALG cargado. Para los operadores de nube DACH, esto significa en la práctica: casi todas las flotas productivas de EC2, Compute Engine y VM de Azure necesitan un parche o una solución alternativa limpia dentro de las próximas 72 horas.
Lo más importante en resumen
- SSH-Foothold es la puerta de entrada real: CVE-2026-31431 no es explotable de forma remota, sino que requiere una sesión local. En entornos de nube con claves filtradas, configuraciones de bastión débiles o corredores CI comprometidos, esto es suficiente. La vulnerabilidad convierte un acceso de shell normal en root.
- El alcance de la carga de trabajo es amplio, no profundo: Afectados son AWS EC2, VM de Azure, GCP Compute Engine, servidores Hetzner, hosts de contenedores, nodos de trabajo de Kubernetes, corredores CI y bastiones SSH. Los servicios de contenedores gestionados (Fargate, Cloud Run) solo están afectados indirectamente, siempre que el host subyacente no esté parcheado.
- La solución alternativa antes del parche es legítima: Quien no pueda parchear en 72 horas, desactiva AF_ALG a través de la lista negra de modprobe. Esto evita el exploit, pero cuesta rendimiento en operaciones criptográficas que utilizan la interfaz del kernel. Probar antes de la producción.
Relacionado:Container-Image-Diet 2026: Distroless, Wolfi, Chainguard / State of FinOps 2026
Lo que sucedió el 04.05.2026
¿Qué es CVE-2026-31431? CVE-2026-31431, internamente denominado „copyfail“, es una vulnerabilidad de escalada de privilegios local en el kernel de Linux. Se encuentra en la interfaz AF_ALG de la API Crypto del kernel y combina un error en el componente ONC-ESN con un primitivo de escritura en la caché de páginas. Un atacante con acceso normal a la shell del sistema puede así escalar a privilegios de root. Están afectadas todas las distribuciones de Linux cuyo kernel incluya la implementación AF_ALG de 2017 o posterior.
El Proof-of-Concept de Theori es un exploit de 732 líneas en Python. Lo destacable no es el tamaño, sino el modo de descubrimiento: el agente de IA autónomo de Theori escaneó la vulnerabilidad, construyó el primitivo del exploit y completó el PoC en aproximadamente una hora. CISA incluyó la vulnerabilidad en el catálogo KEV el mismo día, y CrowdStrike Threat Intelligence confirmó su explotación activa.
Para las agencias federales de EE. UU., la inclusión en el KEV implica un plazo estricto para aplicar el parche. Para las organizaciones de DACH esto no es vinculante, pero el mensaje es claro: un exploit público más una explotación activa más una amplia cobertura de distribuciones genera presión para aplicar el parche, independientemente de la autoridad supervisora.
Dónde se ven afectadas concretamente las cargas de trabajo en la nube
El alcance a través de los hiperescaladores es alto. AWS Linux 2 y Amazon Linux 2023 cargan AF_ALG por defecto. Azure Ubuntu, Azure RHEL y Azure SUSE también. Google Compute Engine con Debian, Ubuntu o sistema operativo optimizado para contenedores también. Quienes operan EC2-Auto-Scaling-Groups, AKS-Worker-Nodes, GKE-Knoten o clústeres de Kubernetes autoalojados deberían verificar el estado del parche por imagen y por grupo de nodos.
La infraestructura de CI y construcción es la segunda zona de riesgo silenciosa. GitHub-Actions-Self-Hosted-Runner, GitLab-Runner en hosts propios, Jenkins-Agents y Buildkite-Worker suelen ejecutarse en Linux estándar. Un trabajo de Pull-Request comprometido con Shell-Stage tiene así potencialmente Root en el host de construcción. La recomendación estándar «Cambiar el Runner regularmente» se convierte en una obligación en esta situación.
Los servicios de contenedores gestionados alivian parcialmente. AWS Fargate, Google Cloud Run y Azure Container Apps abstraen el host de la carga de trabajo. Los operadores de la plataforma parchean los hosts, los clientes solo necesitan ajustar sus imágenes de contenedores si el contenedor mismo realiza operaciones privilegiadas. Sin embargo, quienes ejecutan contenedores con hostPID, hostNetwork o Privileged-Mode, o operan trabajadores de Kubernetes por sí mismos, vuelven al modo de parcheo obligatorio.
«Se confirma la explotación activa en la naturaleza. Todos los sistemas Linux no parcheados con AF_ALG habilitado están en riesgo.»
CrowdStrike Threat Intelligence, 04.05.2026
Ruta de parcheo en 72 horas
La ruta rápida en flotas de nube productivas suele ser la misma. Primero: Inventario. ¿Qué versiones de Linux están en ejecución, con qué kernel, en qué grupos de autoescalado o grupos de nodos? Los clientes de AWS obtienen esto de Systems Manager Inventory, Azure de Update Management, GCP de OS Config. Quien no lo tenga, construye durante una hora un inventario ad-hoc con SSM-Run-Command o Ansible-Ad-hoc.
Segundo: Despliegue del parche en oleadas. Primero la fase, luego el 10 por ciento de la producción, luego el resto. En los grupos de autoescalado, esto significa una nueva AMI con el kernel parcheado y un reemplazo en rodillo. En Kubernetes, una actualización del grupo de nodos, idealmente con protección PDB en las cargas de trabajo principales. Tercero: Verificación. Por cada máquina parcheada, un solo comando es suficiente: uname -r contra el kernel de corrección específico de la distro.
Quien no pueda mantener la ruta de 72 horas tiene la solución alternativa. El archivo /etc/modprobe.d/blacklist-af_alg.conf con la línea install af_alg /bin/false evita que el módulo se cargue al iniciar. Las sesiones existentes necesitan un reinicio para que el cambio surta efecto. Cuidado: TLS-Offloading, stacks de cifrado de discos y conexiones HSM que utilizan AF_ALG vuelven a los fallbacks de User-Space. Medir el impacto en el rendimiento antes de la producción.
Preguntas frecuentes
¿Los contenedores en servicios gestionados como Fargate o Cloud Run están directamente afectados?
Directamente no. El hiperescalador parchea el host, el contenedor debajo no ve la interfaz del kernel. Indirectamente sí: si un contenedor se ejecuta con modo privilegiado o hostPID o la aplicación misma inicia operaciones AF_ALG, el exploit también puede ser relevante en tales entornos. Las cargas de trabajo web estándar sin operaciones de criptografía del kernel no son el objetivo principal.
¿Qué distribuciones de Linux tienen parches el 05.05.2026?
Red Hat Enterprise Linux 8 y 9 tienen actualizaciones a través del canal regular de erratas. Ubuntu LTS 20.04, 22.04 y 24.04 tienen parches en el Security-Pocket. Debian Stable tiene la actualización en el repositorio Stable-Security. Amazon Linux 2 y Amazon Linux 2023 están disponibles a través de yum/dnf. SUSE Linux Enterprise 15 está en el canal de mantenimiento. Arch y openSUSE Tumbleweed ruedan con el kernel Mainline. Alpine Linux suele seguir dentro de las 48 horas.
¿Cuál es el impacto en el rendimiento del parche AF_ALG?
Muy dependiente de la carga de trabajo. Un servidor web estándar con OpenSSL no usa AF_ALG y no tiene impacto. El cifrado de disco con dm-crypt recurre a AES en el espacio de usuario, lo que en CPUs modernas con AES-NI supone una pequeña diferencia. Las conexiones HSM y PKCS11 que usan AF_ALG para la abstracción de hardware pueden volverse significativamente más lentas. Antes del parche productivo, medir un breve pico de carga en un nodo de ensayo.
¿Es suficiente un reinicio después del parche o se necesita más?
Un parche en el archivo de imagen del kernel solo surte efecto después de un reinicio. En grupos de autoescalado, prácticamente a través de una nueva AMI con kernel parcheado. En Kubernetes, a través de una actualización del grupo de nodos. El parcheo en vivo mediante kpatch o kgraft es posible en algunas distribuciones, pero no en todas. Quien no tenga parcheo en vivo en su stack, planifica un reinicio gradual dentro del plazo de 72 horas.
¿Qué pasa con las instancias en la nube basadas en ARM como AWS Graviton?
También afectadas. AF_ALG es una interfaz del kernel, independientemente de la arquitectura de la CPU. AWS Graviton, Azure Cobalt y Google Tau-T2A funcionan todas con las mismas distribuciones de Linux que las instancias x86. La ruta del parche es idéntica: actualización específica de la distribución, reinicio, verificación.
Más del MBF Media Netzwerk
- SecurityToday: Resumen de la RSA Conference 2026 – Tareas de CISO DACH sobre PQC, detección, consolidación de proveedores
- Digital Chiefs: CIOs bajo presión – 62 por ciento en gobernanza de IA
- MyBusinessFuture: EUDI Wallet desde el lanzamiento piloto 2026 – Infraestructura de identidad para la PYME
Fuente de la imagen de portada: Pexels / Brett Sayles
