Bad Epoll CVE-2026-46242: la vulnerabilidad en el kernel de Linux que da acceso root con un 99% de fiabilidad y también afecta a Android

El 3 de julio de 2026, el investigador Jaeyoung Chung, estudiante de doctorado del CompSec Lab de la Universidad Nacional de Seúl, publicó el análisis completo de Bad Epoll (CVE-2026-46242), una vulnerabilidad de carrera use-after-free en el subsistema epoll del kernel de Linux que permite a cualquier usuario local sin privilegios escalar a root con una fiabilidad aproximada del 99%. El fallo afecta a servidores Linux, escritorios y dispositivos Android que ejecutan kernel v6.4 o superior. No existe ningún workaround posible porque epoll no puede desactivarse: está integrado en el núcleo de cómo Linux gestiona la concurrencia de red y es utilizado por prácticamente todos los servicios de red de alto rendimiento, runtimes y navegadores web. Chung presentó la vulnerabilidad como zero-day en el programa Google kernelCTF, que recompensa exploits funcionales con más de 71.000 dólares. El parche fue integrado en el repositorio principal del kernel (commit a6dc643c6931) en abril de 2026, pero lleva meses allí sin que muchas distribuciones hayan incorporado el backport, y la divulgación pública completa junto con el código del exploit llegó solo el 3 de julio, 70 días después de que el parche aterrizara en mainline sin anuncio formal de seguridad.

‍

¿Qué se sabe de Bad Epoll (CVE-2026-46242)?

Los hechos documentados por The Hacker News, SentinelOne, Breached.Company, The CyberSec Guru, Latest Hacking News y el propio repositorio público de Chung son los siguientes:

• Vulnerabilidad: bug de carrera temporal (race condition) de tipo use-after-free en la función ep_remove() y su auxiliar ep_remove_file() dentro del subsistema eventpoll del kernel de Linux. La función limpia el campo file->f_ep bajo un lock, pero continúa usando el puntero @file dentro de la sección crítica. Una llamada concurrente a __fput() puede observar el NULL transitorio, omitir eventpoll_release_file() y liberar la estructura struct eventpoll vigilada, produciendo corrupción de memoria en el heap del kernel.
• CVSS 7.8 (High): vector de ataque local, complejidad baja, privilegios bajos, sin interacción del usuario, impacto alto en confidencialidad, integridad y disponibilidad.
• Alcance: Linux desktops y servidores con kernel v6.4 o superior, y dispositivos Android. Los Pixel 8 (kernel v6.1) no están afectados. Los Pixel 10 y dispositivos con kernel v6.6+ deben aplicar las actualizaciones de seguridad de Google en cuanto estén disponibles. El exploit Android completo no es aún público, pero el equipo de Chung ha confirmado corrupción de memoria y está desarrollando la cadena completa.
• Fiabilidad del exploit: 99%. Ganar una carrera temporal de forma fiable es habitualmente el obstáculo principal en la explotación de bugs de kernel. El diseño de Chung encadena cuatro descriptores de fichero epoll vinculados —dos pares que disparan la carrera repetidamente mientras otros actúan como víctimas— y amplía artificialmente la ventana de seis instrucciones para conseguir una fiabilidad cercana al 99% sin provocar caídas del sistema.
• Sin workaround posible: epoll no puede desactivarse. Está compilado en el kernel de cualquier distribución Linux de propósito general (CONFIG_EPOLL siempre está habilitado). No hay mitigación que elimine la superficie de ataque; solo el parche cierra el agujero.
• El exploit puede dispararse desde dentro del sandbox de Chrome: Bad Epoll es uno de los pocos bugs de kernel que puede ser activado desde el sandbox del renderer de Chrome, lo que amplía significativamente los escenarios de explotación más allá de un shell local.
• Introducido por un commit de 2023: un único cambio de abril de 2023 (commit 58c9b016e128) al código epoll introdujo dos race conditions separadas en unas 2.500 líneas de código. La primera fue encontrada y corregida como CVE-2026-43074. Bad Epoll es la segunda y tardó meses adicionales en ser detectada.
• El ángulo de la IA: el mismo bloque de código epoll donde se esconde Bad Epoll fue revisado por Mythos, el modelo de IA de Anthropic desplegado en el marco del Proyecto Glasswing. Mythos encontró CVE-2026-43074, el primer bug, e incluso un investigador independiente publicó después un exploit de nivel 1 para él en kernelCTF. Pero Mythos no detectó Bad Epoll. Chung ofrece dos razones probables: la ventana de carrera tiene solo seis instrucciones de anchura, lo que hace muy difícil imaginar la intercalación exacta de hilos incluso mirando el código directamente; y una vez parcheado CVE-2026-43074, Bad Epoll normalmente no activa KASAN, el detector de errores de memoria del kernel, por lo que no hay señal de runtime que indique que algo está mal.
• Sin explotación activa confirmada: CVE-2026-46242 no está en el catálogo KEV de CISA a fecha de publicación, y no se ha reportado uso en ataques reales. Sin embargo, el código del exploit es público, funcional y altamente fiable.
• Familia de bugs: Bad Epoll se une a la serie documentada de bugs que pueden rootear Android denominada «Bad»: Bad Binder, Bad IO_uring, Bad Spin, y ahora Bad Epoll. De los aproximadamente 130 exploits ejecutados en kernelCTF, solo unos diez son candidatos a rootear Android. Bad Epoll es uno de ellos porque epoll no es un módulo opcional.

‍

Por qué una vulnerabilidad local en el kernel de Linux es un riesgo de primer orden para las empresas

Una escalada de privilegios local puede parecer menos urgente que un RCE remoto. En la práctica, es exactamente lo contrario para la mayoría de los ataques reales:

1. La escalada de privilegios local es el segundo paso de casi todos los ataques avanzados exitosos. Los actores de amenazas rara vez entran directamente con privilegios de administrador. El patrón habitual es acceso inicial con privilegios bajos —a través de phishing, explotación de aplicación web, paquete npm malicioso o cualquier vector de acceso remoto— seguido de una LPE para alcanzar persistencia y movimiento lateral. Con un exploit local que funciona el 99% de las veces en cualquier servidor Linux, la brecha entre «acceso limitado» y «control total del host» se cierra de forma prácticamente determinista.
2. Linux está en todas partes donde más importa: servidores cloud, contenedores, CI/CD y Android. La superficie de ataque de Bad Epoll no es un servidor legacy olvidado: son los runners de CI/CD donde se compila el código de producción, los nodos de Kubernetes que sirven aplicaciones críticas, los servidores multi-tenant donde conviven múltiples clientes, y los cientos de millones de dispositivos Android en manos de empleados corporativos. Un compromiso inicial en cualquiera de estos entornos más Bad Epoll equivale a control total del host.
3. Los entornos multi-tenant y compartidos son el escenario más crítico. En un servidor con múltiples usuarios o en un nodo de Kubernetes donde varios workloads comparten kernel, Bad Epoll convierte un proceso comprometido de bajo privilegio —una aplicación web explotada, un token de CI robado— en root sobre el host completo y, potencialmente, en fuga de contenedor.
4. El exploit es público, fiable y puede dispararse desde Chrome. No es una vulnerabilidad teórica: hay código funcional, con documentación detallada, que logra root con una fiabilidad del 99%. Y puede activarse desde el sandbox del renderer de Chrome, lo que significa que una web maliciosa visitada desde un servidor Linux podría ser el vector de entrada.

‍

Cómo funciona la cadena de explotación de Bad Epoll

La cadena documentada por Chung en su repositorio público y analizada por The CyberSec Guru y Breached.Company sigue este patrón:

1. Preparación: encadenamiento de cuatro descriptores de fichero epoll vinculados. El atacante con código local de bajo privilegio crea cuatro instancias de epoll enlazadas de forma específica. Dos pares disparan la carrera temporal de forma repetida mientras los otros actúan como víctimas.
2. Disparo de la race condition en ep_remove(). La función limpia file->f_ep bajo lock pero continúa usando el puntero después. Una llamada concurrente a __fput() puede liberar la struct eventpoll vigilada mientras ep_remove() todavía la está usando.
3. Corrupción de memoria: escritura de ocho bytes en memoria liberada. Ganar la carrera produce una escritura fuera de los límites en memoria del heap del kernel, concretamente en objetos del slab kmalloc-192, y una llamada misdirected a kmem_cache_free() contra el slab incorrecto.
4. Control de un objeto de fichero del kernel. El atacante dirige la corrupción para tomar control de un objeto struct file en el heap del kernel.
5. Lectura arbitraria de memoria del kernel vía /proc/self/fdinfo. Con el objeto de fichero bajo control, el exploit puede leer memoria arbitraria del kernel, obteniendo las direcciones necesarias para el paso siguiente.
6. Cadena ROP y shell root. El exploit construye una cadena return-oriented programming para ejecutar código en contexto de kernel y spawna un shell root.

‍

Lecciones clave y mitigaciones disponibles

Acción inmediata: aplicar el parche del kernel

• Priorizar el parche en servidores Linux accesibles desde internet, runners CI/CD, nodos Kubernetes y sistemas multi-tenant. El parche está disponible en el commit a6dc643c6931 del repositorio principal del kernel. Verificar si la distribución en uso ha publicado ya el backport: Debian tiene la build en testing. Aplicar el parche y reiniciar el sistema.
• Inventariar la versión de kernel en toda la flota Linux. El fallo afecta a kernels v6.4 y superiores. Cualquier host con una versión de kernel sin el parche que cubre este CVE es vulnerable mientras tenga usuarios locales o procesos con acceso de bajo privilegio.
• Para dispositivos Android: aplicar las actualizaciones de seguridad de Google en cuanto estén disponibles para el modelo. Los Pixel 8 (kernel v6.1) no están afectados. El exploit completo de Android aún no es público, pero el código de prueba de concepto para corrupción de memoria sí lo es.

Mitigaciones de reducción de riesgo mientras se parchea

• Habilitar KASLR y SLUB randomization. Aumentan la barrera técnica de explotación porque la técnica de Chung para ampliar la ventana de carrera depende de un layout predecible del heap. No eliminan la vulnerabilidad, pero elevan el esfuerzo requerido.
• SELinux o AppArmor en modo enforced. Pueden restringir lo que un proceso escalado a root tiene permitido hacer, aunque no impiden la escalada en sí misma. Combinados con el parche son la postura correcta.
• Restringir el acceso de bajo privilegio a servidores críticos. Minimizar el número de usuarios locales y de procesos con capacidad de ejecutar código en servidores donde el impacto de una LPE sería mayor.

Detección post-explotación

• Bad Epoll deja muy pocas trazas durante la explotación porque la carrera no activa KASAN. La detección debe centrarse en los síntomas post-explotación: nuevos binarios setuid no autorizados, modificaciones no planificadas a sudoers, nuevas cuentas con privilegios, cambios en la configuración de arranque, o eventos de autenticación que siguen inmediatamente a un compromiso de bajo privilegio conocido.
• Centralizar la recolección de ring buffer del kernel y volcados de memoria de los endpoints Linux para análisis retrospectivo.
• Configurar alertas para soft lockups repetidos, stalls de RCU o general protection faults originados en fs/eventpoll.c.

‍

La ciberseguridad como prioridad estratégica

Bad Epoll es un recordatorio incómodo de que el código más revisado no es necesariamente el más seguro. Un único commit de 2023 introdujo dos race conditions en 2.500 líneas de código epoll. Un modelo de IA de frontera revisó ese código, encontró la primera, y no encontró la segunda. La segunda estuvo tres años en mainline antes de que un investigador humano, buscando específicamente ese tipo de bug, la detectara. Para los equipos de seguridad y las organizaciones que administran flotas Linux en producción, la pregunta de hoy es directa: ¿sabes exactamente en qué versión de kernel están tus servidores, tus runners CI/CD y tus nodos Kubernetes, y cuánto tiempo llevas sin aplicar actualizaciones de kernel por evitar un reinicio?

‍

Apolo Cybersecurity: auditoría de versiones de kernel y priorización de parches en flotas Linux

En Apolo Cybersecurity ayudamos a organizaciones a gestionar el riesgo de vulnerabilidades de kernel como Bad Epoll: inventario de versiones de kernel en toda la flota Linux, identificación de sistemas prioritarios para parchear (servidores multi-tenant, nodos Kubernetes, runners CI/CD), validación del estado de backports en distribuciones en uso, evaluación del impacto de una LPE en la arquitectura de red de la organización, y configuración de alertas de detección post-explotación en SIEM y EDR.

Si administras servidores Linux y no tienes confirmación de qué versión de kernel está en producción y si incluye el parche de Bad Epoll, este lunes es el momento de verificarlo.

‍