CVE-2026-46242 'Bad Epoll': exploit con 99% de confiabilidad transforma usuario común en root en el kernel Linux
Investigador de la Universidad Nacional de Seúl publicó exploit funcional para CVE-2026-46242: cualquier proceso local sin privilegios puede obtener root en kernels Linux 6.4 a 6.12 y en dispositivos Android.
Jaeyoung Chung, doctorando del CompSec Lab de la Universidad Nacional de Seúl, hizo público este viernes (3 de julio) un exploit funcional para el CVE-2026-46242, apodado "Bad Epoll". Cualquier proceso local sin privilegios puede escalar a root. Kernels entre las versiones 6.4 y 6.12.67 están afectados, cubriendo la generación más reciente de distribuciones enterprise de Linux y dispositivos Android en todo el mundo.
¿Qué hace la falla y por qué el radio de impacto es amplio?
El CVE-2026-46242 es un use-after-free de race condition en el subsistema epoll del kernel. El epoll coordina eventos de I/O de alto rendimiento y está presente en prácticamente todos los servidores web, brokers de mensajería y bases de datos Linux, lo que coloca el código vulnerable en actividad continua en casi toda la infraestructura Linux moderna.
La falla ocurre cuando dos descriptores de archivo epoll monitorean uno al otro y ambos se cierran casi al mismo tiempo: el kernel libera la memoria de un objeto mientras todavía está escribiendo en ella por el otro, corrompiendo la memoria interna. La ventana de race tiene solo seis instrucciones de ancho. Chung encadenó cuatro objetos epoll para amplificar la probabilidad de éxito, alcanzando un 99% de confiabilidad en el LTS 6.12.67 y un 98% en el COS 121-18867, la imagen base estándar de las VMs de Google Cloud Compute Engine.
Bad Epoll puede activarse desde dentro del sandbox del renderer de Chrome, perímetro que bloquea la mayoría de los errores de kernel conocidos. De los 130 exploits ya enviados al programa Google kernelCTF a lo largo de su historia, aproximadamente diez son candidatos para rootear dispositivos Android, y el CVE-2026-46242 está en ese grupo. Google pagó a Chung el bounty base de $71,337 por el descubrimiento.
¿Por qué el parche tardó cinco meses en llegar al conocimiento público?
La falla fue reportada el 17 de febrero de 2026. El commit de corrección a6dc643c6931 llegó al kernel upstream el 24 de abril, pero el embargo estándar del programa Google kernelCTF retuvo la divulgación pública hasta esta semana. El código vulnerable fue introducido en el kernel 6.4 a través del commit 58c9b016e128, de abril de 2023; kernels de la rama 6.1-LTS no están afectados.
En el mismo subsistema, el CVE-2026-43074, una race condition adyacente en el mismo código epoll, había sido identificado por escaneo automatizado con modelo de IA antes de esta divulgación. Bad Epoll quedó fuera de la detección. Según el análisis técnico de Chung, después de corregir el primer bug, la falla adyacente dejó de activar el sanitizer de memoria del kernel, eliminando el rastro de runtime del cual herramientas de detección automatizada dependen. El patrón es relevante para cualquier equipo que use escáneres basados en IA para la triage de código: cuando dos bugs coexisten en el mismo camino de ejecución, corregir uno puede enmascarar al otro ante cualquier escáner que dependa de evidencia de ejecución para señalar.
Exposición en infraestructura global y qué hacer ahora
Ubuntu 24.04 LTS, con kernel 6.8 estándar, y Debian 13 están en el rango afectado. Google confirmó que instancias COS 121 ya están recibiendo el kernel corregido de forma automática. AWS y Azure no publicaron boletines individuales hasta el cierre de esta edición; equipos que mantienen kernels fijos en imágenes personalizadas necesitan verificar si el commit a6dc643c6931 está incorporado antes de expandir capacidad.
En Europa, el NIS2 obliga a operadores de infraestructura crítica a documentar vulnerabilidades con potencial de escalada de privilegios y a notificar a las autoridades competentes dentro de las 72 horas posteriores a la explotación confirmada. Ninguna explotación in-the-wild ha sido reportada hasta el cierre de esta edición, pero un exploit con 99% de confiabilidad disponible públicamente elimina la barrera técnica para ataques oportunistas.
El vector de mayor riesgo en entornos empresariales son nodos host de clusters de Kubernetes con namespaces de usuario no restringidos, configuración presente por defecto en varias distribuciones gestionadas de Kubernetes. En pipelines de CI/CD compartidos, cualquier job con código comprometido vía supply chain puede usar Bad Epoll para escalar del aislamiento de contenedor al host y acceder a secretos de otros equipos. Centros de delivery en India, donde TCS, Infosys y Wipro operan Kubernetes multi-tenant para clientes en Europa, EE. UU. y Asia-Pacífico, tienen una superficie de ataque particularmente amplia. La actualización de kernel requiere ventana de mantenimiento, pero postergar la corrección ante un exploit público de alta confiabilidad prolonga innecesariamente el riesgo.