Bad Epoll no es solo otra vulnerabilidad crítica del kernel de Linux. Es una señal incómoda para una industria que empezaba a mirar los modelos de inteligencia artificial como si fueran capaces de encontrar, casi por defecto, cualquier fallo explotable en código complejo. La realidad vuelve a ser más áspera: incluso una IA avanzada puede revisar una zona sensible del kernel, encontrar un bug serio y pasar por alto otro en el mismo camino.
La vulnerabilidad, identificada como CVE-2026-46242, afecta al subsistema epoll del kernel de Linux y ha sido documentada por el investigador Jaeyoung Chung. Su importancia técnica está en la combinación de dos elementos conocidos por cualquier equipo de seguridad de bajo nivel: una condición de carrera y un use-after-free. Dicho de forma sencilla, dos rutas de ejecución gestionan de forma concurrente un mismo objeto interno; una libera memoria mientras la otra todavía la usa. Ese pequeño desorden temporal puede abrir la puerta a corrupción de memoria en el kernel.
El caso resulta relevante por tres motivos. Afecta a una función básica de Linux, puede permitir escalada local de privilegios y, según la investigación publicada, fue pasado por alto por Mythos, el modelo de Anthropic usado en el marco de Project Glasswing, pese a que sí detectó otra condición de carrera en la misma zona de código.
Qué es epoll y por qué no se puede apagar sin más
epoll es una pieza estándar de Linux que permite a una aplicación vigilar múltiples descriptores de fichero o conexiones de red de forma eficiente. Servidores web, navegadores, servicios de red, bases de datos, runtimes y muchas aplicaciones modernas dependen de este mecanismo para trabajar con miles de eventos simultáneos sin bloquearse.
Por eso Bad Epoll no tiene una mitigación cómoda basada en desactivar un módulo o retirar una funcionalidad secundaria. A diferencia de otros fallos del kernel ligados a componentes que pueden limitarse o deshabilitarse en determinados entornos, epoll forma parte del funcionamiento normal del sistema. La corrección pasa por aplicar el parche correspondiente o el backport que publique cada distribución.
Según el repositorio técnico del investigador, la vulnerabilidad fue introducida por un cambio de abril de 2023 y quedó corregida en mainline con el commit a6dc643c6931, publicado el 24 de abril de 2026. Los sistemas basados en kernels 6.4 o posteriores pueden verse afectados si no han recibido el parche o una corrección equivalente mantenida por su distribución.
La National Vulnerability Database describe el problema como un UAF en eventpoll, vinculado a la función ep_remove, donde una ruta de ejecución podía seguir usando una estructura mientras otra liberaba o reciclaba memoria. No es un fallo fácil de explicar en una frase, y precisamente ahí está parte de su gravedad: los bugs de concurrencia suelen ser difíciles de detectar, reproducir y corregir bien.
El bug que Mythos no vio
La parte más llamativa del caso no es solo la vulnerabilidad, sino el contexto. Anthropic presentó Project Glasswing en abril de 2026 como una iniciativa para usar capacidades avanzadas de IA en defensa de software crítico, con socios como AWS, Apple, Google, Microsoft, NVIDIA, CrowdStrike, JPMorganChase, la Linux Foundation y otros actores tecnológicos. La compañía explicó entonces que Claude Mythos Preview era un modelo no publicado, orientado a encontrar y explotar vulnerabilidades de software con un nivel muy alto.
Ese planteamiento generó una expectativa lógica: si un modelo de frontera puede auditar código crítico, generar hipótesis y encontrar fallos que a los humanos se les escapan, quizá estemos entrando en una fase nueva para la seguridad ofensiva y defensiva. Y seguramente sea así, pero Bad Epoll recuerda que esa fase no elimina las limitaciones.
El propio write-up de Chung señala que un único commit de 2023 introdujo dos condiciones de carrera distintas en el código de epoll, dentro de una ruta relativamente pequeña. Mythos habría encontrado una de ellas, reportada como CVE-2026-43074, pero no Bad Epoll. La conclusión no debería ser que Mythos no sirve. Encontrar una carrera explotable en el kernel ya es un resultado muy relevante. La lectura más útil es otra: incluso cuando la IA acierta, puede no agotar el espacio de fallos.
El investigador apunta dos razones probables. La primera es que la ventana de carrera era extremadamente estrecha, de apenas unas pocas instrucciones. La segunda es que, tras corregir el otro bug detectado por Mythos, Bad Epoll normalmente no disparaba KASAN, el detector dinámico de errores de memoria del kernel. Sin una señal clara de runtime, el modelo podía carecer de confianza suficiente para marcarlo como fallo real.
Ese matiz importa. Las herramientas de IA no “ven” la verdad del programa de forma absoluta. Razonan a partir de código, patrones, evidencias, contexto y señales. Si el bug depende de un interleaving muy concreto entre hilos, no deja trazas claras y además se esconde en una zona de lógica concurrente, el análisis se vuelve difícil incluso para sistemas muy capaces.
Un exploit fiable en una ventana diminuta
Bad Epoll es también un recordatorio de que una ventana de carrera pequeña no equivale a un riesgo pequeño. Según el análisis publicado, el exploit consigue ampliar las posibilidades de acierto y repetir el intento sin provocar un fallo del kernel, hasta alcanzar una fiabilidad cercana al 99 % en determinados objetivos de Google kernelCTF.
Google kernelCTF forma parte del programa de recompensas de vulnerabilidades de Google y está diseñado para que investigadores demuestren técnicas de explotación contra vulnerabilidades del kernel de Linux. Sus reglas contemplan recompensas base para exploits contra la instancia LTS y bonificaciones por estabilidad o por vulnerabilidades 0-day. Esto explica el interés de la comunidad por fallos que no solo son teóricos, sino explotables en condiciones controladas.
El impacto potencial es serio porque hablamos de escalada local de privilegios. Un proceso sin privilegios podría convertirse en root si se cumplen las condiciones necesarias. En entornos Linux de escritorio, servidores multiusuario, contenedores con ciertas configuraciones o sistemas expuestos a cadenas de explotación, esto cambia el modelo de riesgo. En Android, el investigador considera el bug especialmente relevante porque epoll está disponible y no depende de módulos ausentes en muchos dispositivos. Aun así, conviene matizar: el propio repositorio indica que el exploit completo para Android seguía en desarrollo, aunque la prueba de concepto ya activaba el UAF en dispositivos con kernel 6.6 o superior.
Para equipos defensivos, la recomendación práctica es clara: revisar versiones de kernel, aplicar actualizaciones del proveedor y no asumir que la ausencia de crashes o alertas de KASAN implica ausencia de riesgo. Si una distribución usa ramas basadas en 6.4 o posteriores, hay que comprobar si incorpora el parche o su backport.
La lección: IA sí, pero no sola
Bad Epoll llega en un momento en el que muchas organizaciones están incorporando IA a auditorías de código, análisis de vulnerabilidades, generación de exploits controlados, revisión de parches y triage de informes. Es lógico. La capacidad de estos modelos para leer grandes bases de código, cruzar patrones y acelerar hipótesis puede reducir tiempos y ampliar cobertura.
Pero convertir esa ayuda en una sustitución completa del investigador humano sería un error. La seguridad del kernel, y en general la seguridad de sistemas complejos, sigue dependiendo de intuición, experiencia, técnicas dinámicas, fuzzing, revisión manual, modelado de concurrencia, conocimiento de mitigaciones y capacidad para transformar un fallo aparentemente improbable en un exploit real.
La IA puede encontrar vulnerabilidades que un equipo humano tardaría semanas en localizar. También puede generar ruido, sobredimensionar hallazgos o pasar por alto bugs con señales débiles. El talento humano puede detectar impacto donde una herramienta ve una carrera demasiado estrecha. Y las herramientas clásicas, desde sanitizers hasta fuzzers y análisis estático, siguen aportando señales que ningún modelo debería ignorar.
El futuro razonable no es elegir entre IA o investigadores. Es un modelo híbrido. IA para ampliar superficie de análisis, proponer rutas, revisar código, generar pruebas y ayudar en triage. Humanos para validar, priorizar, entender impacto, explotar de forma controlada, corregir bien y decidir qué riesgo es aceptable.
Bad Epoll no desmonta el valor de Mythos ni de Project Glasswing. Lo aterriza. La IA ya es una herramienta necesaria en investigación de vulnerabilidades, pero todavía no es suficiente. Y quizá esa sea la noticia más importante para quienes trabajan en ciberseguridad defensiva: el criterio humano no ha quedado obsoleto. Se ha vuelto más valioso porque ahora debe gobernar una nueva generación de herramientas muy potentes, pero no infalibles.
Preguntas frecuentes
¿Qué es Bad Epoll?
Es una vulnerabilidad del kernel de Linux, identificada como CVE-2026-46242, que afecta al subsistema epoll y combina una condición de carrera con un use-after-free.
¿Qué puede permitir esta vulnerabilidad?
En determinadas condiciones, puede permitir que un proceso local sin privilegios escale a root. El investigador también señala impacto potencial en Android, aunque el exploit completo para Android estaba en desarrollo.
¿Qué versiones pueden estar afectadas?
El fallo fue introducido en 2023 y afecta a kernels basados en la versión 6.4 o posteriores si no han recibido el parche o un backport de seguridad.
¿Por qué es importante que Mythos no lo encontrara?
Porque muestra que incluso modelos avanzados de IA pueden pasar por alto vulnerabilidades reales en código crítico, especialmente cuando hay concurrencia, ventanas de carrera muy pequeñas y pocas señales dinámicas.
¿Cuál es la mitigación recomendada?
Aplicar el parche upstream correspondiente o las actualizaciones de seguridad publicadas por cada distribución. epoll no es una funcionalidad que pueda desactivarse de forma sencilla sin afectar al sistema.
