Tres fallas del kernel de Linux ya se explotan: el plazo de CISA venció hace dos semanas y a tus servidores les aplica igual

El 18 de septiembre de 2026, CISA agregó tres vulnerabilidades del kernel de Linux a su catálogo de Vulnerabilidades Conocidas Explotadas y dio tres días para corregirlas. El plazo venció el 21 de septiembre y hoy, dos semanas después, la mayoría de los servidores Linux fuera del gobierno de Estados Unidos sigue corriendo el kernel vulnerable. La obligación legal es de las agencias civiles federales estadounidenses. El código vulnerable está en cualquier distribución Linux estándar, la misma que corre en AWS, Azure, GCP o en el rack de tu propio centro de datos.

Tres fallas, tres rutas de ataque distintas

No es una vulnerabilidad, son tres, y no se parecen entre sí.

CVE-2025-39682 (CVSS 9.8 según NVD, 7.0 según Red Hat) vive en la ruta de recepción de TLS del kernel, en la función tls_sw_recvmsg(). El fallo deja pasar un registro de longitud cero del rx_list sin verificar su tipo, lo que rompe las suposiciones de copia cero en los registros TLS siguientes. Según el aviso de Red Hat, es explotable de forma remota, sin privilegios ni interacción del usuario, pero sólo cuando el sistema tiene kernel TLS (kTLS) activo. Si tu stack no usa kTLS, esta ruta de ataque específica no te toca, aunque el kernel vulnerable sigue estando ahí.

CVE-2026-53266 (CVSS 8.8 según la mayoría de las fuentes, 7.5 según el aviso de Red Hat) es una escritura fuera de límites en el objetivo SNAT de ebtables, dentro de netfilter bridge, durante la reescritura de direcciones ARP. Aquí los boletines no coinciden: Red Hat la describe como explotable por red con complejidad alta, el registro de cve.org la describe como local y de complejidad baja. Lo que sí coinciden es que requiere privilegios bajos y que afecta a cualquier sistema con reglas SNAT de ebtables sobre tráfico ARP, algo común en configuraciones de puente de red y en algunos entornos de contenedores.

CVE-2025-39964 (CVSS 7.8, 7.3 en la escala de Red Hat) es una condición de carrera en los sockets AF_ALG, la interfaz criptográfica del kernel. Escrituras concurrentes sobre el mismo socket pueden dejar el estado interno inconsistente y provocar una caída del sistema o corrupción en operaciones criptográficas. Es estrictamente local: requiere una cuenta en la máquina, pero no privilegios de administrador.

Tres superficies: una de red condicionada, una en disputa entre red y local, y una local pura. Tratarlas como "la vulnerabilidad del kernel" es el primer error.

Lo que CISA obligó, y a quién

La directiva BOD 26-04, "Prioritizing Security Updates Based on Risk", entró en vigor el 10 de junio de 2026 y sustituyó a la antigua BOD 22-01. En vez de dar el mismo plazo fijo a todo lo que entra al catálogo KEV, calcula el plazo con cuatro variables: exposición del activo, estatus en el catálogo KEV, si existe automatización del exploit, y el impacto técnico tras la explotación. El reloj empieza cuando ocurre primero: que CISA agregue la falla al catálogo, o que la agencia la detecte en un activo propio.

Para estos tres CVEs, el resultado fue un plazo de tres días en activos expuestos a internet y catorce días en activos internos, con el 2 de octubre como fecha límite para lo interno. La obligación aplica sólo a agencias civiles federales de Estados Unidos. No obliga a una empresa en México, en el resto de Latinoamérica ni a una agencia estatal de EU que no sea del poder ejecutivo civil.

Lo que no cambia con esa obligación es el riesgo técnico. El reporte de The Hacker News y el de Cybersecurity News describen las mismas tres fallas presentes en las ramas estables 6.0, 6.1, 6.6 y 6.12 del kernel, que es lo que corre Ubuntu, Debian, RHEL, SUSE y cualquier distro derivada de esas líneas. El BOD le dice a una agencia federal cuándo parchar. El kernel vulnerable no distingue si lo corre una agencia o una empresa privada.

Los datos duros

CVE	CVSS	Componente	Vector
CVE-2025-39682	9.8	TLS receive path (tls_sw_recvmsg)	Red, condicionado a kTLS activo
CVE-2026-53266	8.8 (Red Hat: 7.5)	netfilter bridge, ebtables SNAT/ARP	En disputa: red (Red Hat) o local (cve.org)
CVE-2025-39964	7.8 (Red Hat: 7.3)	AF_ALG socket	Local

Red Hat revisó sus tres avisos el 19 de septiembre de 2026 para reconocer explotación activa y clasificarlas como prioridad alta, citando la existencia de código de exploit público. Ninguna de las tres tiene parche de mitigación completo según los criterios de seguridad de producto de Red Hat para CVE-2025-39964; para CVE-2026-53266 la recomendación mientras no hay parche es deshabilitar la reescritura de direcciones ARP en las reglas SNAT de ebtables o remover esas reglas si no son indispensables.

Qué revisar en tu operación, en orden

1. Identifica la versión de kernel real en cada host, no la versión de la distro. uname -r en cada servidor, incluyendo los nodos de Kubernetes y las instancias detrás de autoescalado que se crean a partir de una imagen base vieja.
2. Separa lo expuesto a internet de lo interno. El riesgo de CVE-2025-39682 es más urgente en cualquier servidor que termine conexiones TLS directamente en el kernel (kTLS), típico en proxies de alto rendimiento y balanceadores que delegan el cifrado al sistema operativo.
3. Pregúntale a tu proveedor de nube o de hosting si ya aplicó el parche del paquete kernel, no si reinició las instancias. Un reinicio sin actualizar el paquete del kernel deja la misma versión vulnerable corriendo otra vez.
4. Si usas parcheo en caliente (kpatch en RHEL, Livepatch en Ubuntu, kgraft en SUSE), confirma que el parche específico para estos tres CVEs ya está en el catálogo de tu proveedor de live patching. El parcheo en caliente cubre vulnerabilidades críticas y altas sin reiniciar, pero no sustituye la actualización completa del kernel en la siguiente ventana de mantenimiento.
5. Revisa si usas ebtables con reglas SNAT sobre ARP. Si no las usas, CVE-2026-53266 no te aplica directamente; si las usas y no puedes parchar de inmediato, retira esas reglas como mitigación temporal.

Dónde la respuesta obvia es la equivocada

"Reiniciar el servidor" no es "aplicar el parche". Reiniciar sin que el paquete del kernel se haya actualizado primero vuelve a cargar la misma versión vulnerable. Y "actualizar el kernel" tampoco implica reiniciar de inmediato: el parcheo en caliente permite cerrar estas tres fallas sin tumbar procesos, que es justo el motivo por el que existen kpatch, Livepatch y kgraft para cargas de trabajo que no toleran una ventana de mantenimiento.

Tampoco todo el parque de servidores corre el mismo riesgo. Si una máquina no tiene kTLS activo, no carga el módulo AF_ALG y no usa ebtables con SNAT sobre ARP, las tres rutas de explotación descritas aquí no tienen superficie en esa máquina específica, aunque el kernel subyacente siga siendo la misma versión. Parchar sigue siendo lo correcto, pero la urgencia relativa entre tus cien servidores no es uniforme, y tratarlos como si lo fuera gasta la misma ventana de mantenimiento en lo urgente y en lo que puede esperar al ciclo normal.

Ese tipo de inventario (qué host usa qué módulo, qué está expuesto y qué es interno) es exactamente lo que distingue una respuesta a boletines de seguridad que funciona de una que sólo parece ordenada. Mantener esa foto actualizada, parchar sin que se note en producción y sostener la infraestructura entre un aviso de CISA y el siguiente es trabajo continuo, no un proyecto que se cierra una vez; es el terreno de soporte, evolución y hosting tal como lo trabajamos en hivek. Si lo que te falta es automatizar la priorización de estos boletines frente a tu propio inventario, ese fue el problema detrás de una plataforma de ciberseguridad con pipelines de escaneo y remediación que construimos desde cero.

Este patrón (CISA marca, el reloj corre para el gobierno de EU, el riesgo corre para todos los demás) ya se vio con el firewall de Cisco que terminó usándose para instalar el ransomware Qilin y con la falla CVSS 10.0 de Cisco ISE que CISA fijó para el 19 de septiembre. La pregunta que vale la pena hacerse no es si el BOD te obliga. Es cuánto tiempo pasó desde que salió el aviso hasta que alguien en tu operación confirmó, con el número de versión del kernel en la mano, que ya no corres el código vulnerable. Si esa pregunta no tiene respuesta clara hoy, así es como se construye un sistema que la responda.

Fuentes

• CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild, The Hacker News
• CISA Warns of Linux Kernel Vulnerabilities Actively Exploited in Attacks, Cybersecurity News
• Breach Watch, September 20, 2026: Three Linux Kernel Flaws Confirmed Exploited, CISO Platform
• BOD 26-04: Prioritizing Security Updates Based on Risk, CISA
• CVE-2025-39682, Red Hat Customer Portal
• CVE-2025-39964, Red Hat Customer Portal
• CVE-2026-53266, Red Hat Customer Portal