Tres fallas del kernel de Linux entraron al catálogo KEV de CISA el 18 de septiembre con evidencia de explotación activa, y la fecha límite para las agencias federales de Estados Unidos es el 21 de septiembre: tres días de margen, uno de los plazos más cortos que la agencia ha fijado este año. En paralelo, y por pura coincidencia de calendario, un investigador publicó código de explotación funcional para otras cuatro vulnerabilidades del mismo kernel que entregan root local. La semana deja al componente más aburrido y más ubicuo del stack —el kernel— como el punto caliente.
Qué pasó
CISA agregó a su catálogo de Known Exploited Vulnerabilities tres CVE del kernel de Linux: CVE-2025-39682 (CVSS 9.8), CVE-2026-53266 (CVSS 8.8) y CVE-2025-39964 (CVSS 7.8). El catálogo las lista con fecha de alta el 18 de septiembre y vencimiento el 21, bajo la directiva BOD 26-04 de priorización por riesgo. Red Hat actualizó sus tres advisories el 19 de septiembre a las 02:00 UTC para reconocer la explotación en el mundo real.
"Este CVE es de alto riesgo y existen exploits públicos conocidos que aprovechan esta vulnerabilidad. Atienda esta vulnerabilidad con alta prioridad." — Red Hat, en los advisories actualizados
No hay detalles públicos de cómo se están explotando, ni confirmación de que formen parte de una sola cadena de ataque. Tampoco hay atribución a un grupo ni indicios de uso en campañas de ransomware: el campo correspondiente en el KEV sigue en "Unknown".
Un día antes, el 18 de septiembre, el investigador Asim Manizada publicó un write-up técnico con exploits funcionales para cuatro fallas distintas de escalada de privilegios local, bautizadas DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) y DiagSpill (CVE-2026-74469). Las reportó al equipo de seguridad del kernel a mediados de julio y esperó a que las distribuciones liberaran los parches antes de publicar. Estas cuatro no están en el KEV y no se han visto usadas en ataques reales.
Por qué importa
Ninguna de las siete es un RCE pre-auth de portada. Todas son escalada local, la pieza que en la vida real casi nunca es el primer paso pero es el segundo en prácticamente todo compromiso serio: el atacante ya tiene una cuenta de bajo privilegio —una webshell, una credencial reutilizada, un contenedor tomado— y necesita salir del cajón. Eso es exactamente lo que estas fallas entregan.
Dónde duele de verdad: hosts multiusuario, nodos de CI/CD, jump servers, hipervisores y cualquier flota de Kubernetes donde un pod comprometido puede convertirse en root del nodo. Manizada dijo que en teoría algunas de sus fallas permitirían escapar de un contenedor, aunque no construyó la prueba. Y el patrón de fondo es el de siempre: el parche existe desde hace semanas, pero la ventana real de exposición la define el ciclo de reinicio, no el ciclo de release. Un kernel no se actualiza en caliente; alguien tiene que aceptar la ventana de mantenimiento.
El detalle técnico
Las tres del KEV están en rutas de red y cripto del kernel:
- CVE-2025-39682 — validación incorrecta de condiciones excepcionales en la ruta de recepción de TLS. Un usuario local autenticado puede provocar divulgación de memoria o DoS.
- CVE-2026-53266 — escritura fuera de límites en la ruta de reescritura ARP del SNAT de ebtables. Permite comportamiento inesperado, DoS o escalada de privilegios local.
- CVE-2025-39964 — condición de carrera con escrituras concurrentes sobre el mismo socket AF_ALG: crash del sistema o corrupción de resultados de operaciones criptográficas, lo que la convierte además en un problema de integridad, no solo de disponibilidad.
De las cuatro de Manizada, tres (DirtyAH6 en IPsec AH6, TUNderflow en TUN/TAP y PPPoEject en PPPoE) solo son alcanzables por un usuario ordinario si los unprivileged user namespaces están habilitados —y muchas distribuciones los traen activos por defecto, que es justo de donde el exploit toma los privilegios de red que necesita. La excepción es DiagSpill (SCTP, sctp_diag): no requiere namespaces ni privilegios especiales, basta con que el módulo esté disponible.
Dos de ellas, DirtyAH6 y DiagSpill, se pueden disparar por red, pero en escenarios estrechos y básicamente para tirar el host: DirtyAH6 contra un equipo que rutee IPv6 y agregue Authentication Header en modo transporte; DiagSpill solo con opciones de SCTP que están apagadas por defecto. Manizada consiguió root remoto con DirtyAH6 únicamente en su laboratorio y moldeando memoria antes; hacerlo desde una posición remota, escribió, "parece extremadamente difícil". Los exploits están afinados a builds específicos y pueden tumbar la máquina: son para sistemas de prueba aislados.
Qué hacer
- Cruza el KEV contra tu inventario hoy. Las tres CVE con explotación activa son la prioridad, no las cuatro con nombre bonito. El plazo federal del 21 de septiembre es un buen benchmark aunque no te aplique.
- Parchea por advisory de tu distro, no por número de versión upstream. Las releases estables con las cuatro correcciones de Manizada son 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 y 7.2.4, pero Debian, Ubuntu, RHEL y SUSE usan su propio versionado y backportean en su calendario. Verifica en el advisory del vendor, no en
uname -r. - Programa el reinicio. Un kernel parcheado que no se reinició sigue corriendo el vulnerable. Si usas live patching, confirma que cubre estos CVE específicos.
- Mitigación temporal si no puedes parchear: deshabilitar unprivileged user namespaces cierra la vía del usuario común a DirtyAH6, TUNderflow y PPPoEject —no a DiagSpill—, y descargar los módulos que no uses (AH6, TUN/TAP, PPPoE, SCTP) reduce superficie. El propio investigador recomienda parchear en lugar de apagar features.
- Prioriza por contexto, no por CVSS. Escalada local pesa mucho más en un nodo de Kubernetes compartido o en un runner de CI que en un laptop de un solo usuario.