6 Min. tiempo de lectura<\/p>\n
CISA ha incluido CVE-2026-31431 el 04.05.2026 en el cat\u00e1logo de vulnerabilidades explotadas conocidas. CrowdStrike confirma la explotaci\u00f3n activa en la naturaleza. Afectados: cualquier instancia de Linux con kernel desde 2017 y m\u00f3dulo AF_ALG cargado. Para los operadores de nube DACH, esto significa en la pr\u00e1ctica: casi todas las flotas productivas de EC2, Compute Engine y VM de Azure necesitan un parche o una soluci\u00f3n alternativa limpia dentro de las pr\u00f3ximas 72 horas.<\/strong><\/p>\n Relacionado:<\/span>Container-Image-Diet 2026: Distroless, Wolfi, Chainguard<\/a> \/<\/span> State of FinOps 2026<\/a><\/p>\n \u00bfQu\u00e9 es CVE-2026-31431?<\/strong> 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\u00e9 de p\u00e1ginas. Un atacante con acceso normal a la shell del sistema puede as\u00ed escalar a privilegios de root. Est\u00e1n afectadas todas las distribuciones de Linux cuyo kernel incluya la implementaci\u00f3n AF_ALG de 2017 o posterior.<\/p>\n El Proof-of-Concept de Theori<\/a> es un exploit de 732 l\u00edneas en Python. Lo destacable no es el tama\u00f1o, sino el modo de descubrimiento: el agente de IA aut\u00f3nomo de Theori escane\u00f3 la vulnerabilidad, construy\u00f3 el primitivo del exploit y complet\u00f3 el PoC en aproximadamente una hora. CISA incluy\u00f3 la vulnerabilidad en el cat\u00e1logo KEV<\/a> el mismo d\u00eda, y CrowdStrike Threat Intelligence confirm\u00f3 su explotaci\u00f3n activa.<\/p>\n Para las agencias federales de EE. UU., la inclusi\u00f3n 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\u00fablico m\u00e1s una explotaci\u00f3n activa m\u00e1s una amplia cobertura de distribuciones genera presi\u00f3n para aplicar el parche, independientemente de la autoridad supervisora.<\/p>\n El alcance a trav\u00e9s 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\u00e9n. Google Compute Engine con Debian, Ubuntu o sistema operativo optimizado para contenedores tambi\u00e9n. Quienes operan EC2-Auto-Scaling-Groups, AKS-Worker-Nodes, GKE-Knoten o cl\u00fasteres de Kubernetes autoalojados deber\u00edan verificar el estado del parche por imagen y por grupo de nodos.<\/p>\n La infraestructura de CI y construcci\u00f3n 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\u00e1ndar. Un trabajo de Pull-Request comprometido con Shell-Stage tiene as\u00ed potencialmente Root en el host de construcci\u00f3n. La recomendaci\u00f3n est\u00e1ndar \u00abCambiar el Runner regularmente\u00bb se convierte en una obligaci\u00f3n en esta situaci\u00f3n.<\/p>\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\u00e1genes 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\u00ed mismos, vuelven al modo de parcheo obligatorio.<\/p>\n \n\u00abSe confirma la explotaci\u00f3n activa en la naturaleza. Todos los sistemas Linux no parcheados con AF_ALG habilitado est\u00e1n en riesgo.\u00bb La ruta r\u00e1pida en flotas de nube productivas suele ser la misma. Primero: Inventario. \u00bfQu\u00e9 versiones de Linux est\u00e1n en ejecuci\u00f3n, con qu\u00e9 kernel, en qu\u00e9 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<\/a>.<\/p>\n Segundo: Despliegue del parche en oleadas. Primero la fase, luego el 10 por ciento de la producci\u00f3n, 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\u00f3n del grupo de nodos, idealmente con protecci\u00f3n PDB en las cargas de trabajo principales. Tercero: Verificaci\u00f3n. Por cada m\u00e1quina parcheada, un solo comando es suficiente: uname -r<\/span> contra el kernel de correcci\u00f3n espec\u00edfico de la distro.<\/p>\n Quien no pueda mantener la ruta de 72 horas tiene la soluci\u00f3n alternativa. El archivo \/etc\/modprobe.d\/blacklist-af_alg.conf<\/span> con la l\u00ednea install af_alg \/bin\/false<\/span> evita que el m\u00f3dulo 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\u00f3n.<\/p>\n Directamente no. El hiperescalador parchea el host, el contenedor debajo no ve la interfaz del kernel. Indirectamente s\u00ed: si un contenedor se ejecuta con modo privilegiado o hostPID o la aplicaci\u00f3n misma inicia operaciones AF_ALG, el exploit tambi\u00e9n puede ser relevante en tales entornos. Las cargas de trabajo web est\u00e1ndar sin operaciones de criptograf\u00eda del kernel no son el objetivo principal.<\/p>\n<\/details>\n Red Hat Enterprise Linux 8 y 9 tienen actualizaciones a trav\u00e9s 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\u00f3n en el repositorio Stable-Security. Amazon Linux 2 y Amazon Linux 2023 est\u00e1n disponibles a trav\u00e9s de yum\/dnf. SUSE Linux Enterprise 15 est\u00e1 en el canal de mantenimiento. Arch y openSUSE Tumbleweed ruedan con el kernel Mainline. Alpine Linux suele seguir dentro de las 48 horas.<\/p>\n<\/details>\n Muy dependiente de la carga de trabajo. Un servidor web est\u00e1ndar 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\u00f1a diferencia. Las conexiones HSM y PKCS11 que usan AF_ALG para la abstracci\u00f3n de hardware pueden volverse significativamente m\u00e1s lentas. Antes del parche productivo, medir un breve pico de carga en un nodo de ensayo.<\/p>\n<\/details>\n Un parche en el archivo de imagen del kernel solo surte efecto despu\u00e9s de un reinicio. En grupos de autoescalado, pr\u00e1cticamente a trav\u00e9s de una nueva AMI con kernel parcheado. En Kubernetes, a trav\u00e9s de una actualizaci\u00f3n 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.<\/p>\n<\/details>\n Tambi\u00e9n 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\u00e9ntica: actualizaci\u00f3n espec\u00edfica de la distribuci\u00f3n, reinicio, verificaci\u00f3n.<\/p>\n<\/details>\n Fuente de la imagen de portada: Pexels \/ Brett Sayles<\/p>\n","protected":false},"excerpt":{"rendered":"~8 Min. Lesezeit<\/span>Lo m\u00e1s importante en resumen<\/h2>\n
\n
Lo que sucedi\u00f3 el 04.05.2026<\/h2>\n
D\u00f3nde se ven afectadas concretamente las cargas de trabajo en la nube<\/h2>\n
\n
\nCrowdStrike Threat Intelligence, 04.05.2026<\/cite>\n<\/p>\n<\/blockquote>\nRuta de parcheo en 72 horas<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfLos contenedores en servicios gestionados como Fargate o Cloud Run est\u00e1n directamente afectados?<\/strong><\/summary>\n
\u00bfQu\u00e9 distribuciones de Linux tienen parches el 05.05.2026?<\/strong><\/summary>\n
\u00bfCu\u00e1l es el impacto en el rendimiento del parche AF_ALG?<\/strong><\/summary>\n
\u00bfEs suficiente un reinicio despu\u00e9s del parche o se necesita m\u00e1s?<\/strong><\/summary>\n
\u00bfQu\u00e9 pasa con las instancias en la nube basadas en ARM como AWS Graviton?<\/strong><\/summary>\n
M\u00e1s del MBF Media Netzwerk<\/h2>\n
\n