Me sorprendió el titular, y por eso me he puesto a revisar todos los detalles que he podido: Bad Epoll, una vulnerabilidad del kernel de Linux que la IA de Mythos no encontró cuando revisó exactamente el mismo código. Nos estábamos acostumbrando —al menos yo— a esa percepción errónea de que un modelo de frontera lo podía todo, que encontraría cualquier vulnerabilidad explotable de cualquier software que analizase, dejando atrás el ingenio de la mente humana para esa tarea. Pues no. Nunca más lejos de la realidad.
Bad Epoll (CVE-2026-46242) fue descubierta y explotada por Jaeyoung Chung, y afecta al subsistema epoll del kernel de Linux. Es un bug que se aprovecha de una mala sincronización entre dos rutas que intentan gestionar el mismo objeto interno de epoll: una condición de carrera (no se respeta el orden correcto de ejecución) que deja al descubierto un use-after-free (acceso a un segmento de memoria que ya no debería usarse tras haberse liberado).
epoll es una función estándar de Linux que permite a un programa monitorizar varios ficheros y conexiones de red a la vez, de forma simultánea. Es una pieza crítica y básica para el funcionamiento de casi cualquier sistema: el propio sistema operativo, los servicios de red y los navegadores se apoyan en ella. Por eso, a diferencia de otros casos, no se puede desactivar para dejar de ser vulnerable.
Este bug permite que un proceso sin privilegios se convierta en root —no solo en escritorios y servidores Linux, sino también en dispositivos Android—. La captura de abajo es la demostración del autor: dos objetivos de Google kernelCTF corriendo en paralelo (una imagen LTS y una COS) que arrancan como usuario normal y terminan con un shell root (uid=0).
Demostración del exploit de Bad Epoll por Jaeyoung Chung. Fuente: repositorio J-jaeyoung/bad-epoll en GitHub.
Fue reportado como 0-day a Google kernelCTF, el programa que recompensa un exploit de kernel de Linux con 71.337 dólares o más. Y hay un matiz que lo hace especialmente serio: Bad Epoll puede dispararse desde dentro del sandbox del renderer de Chrome, el mismo que bloquea casi todos los demás bugs de kernel que se han conocido. Un exploit del renderer podría encadenarse con Bad Epoll para lograr ejecución de código en el kernel.
Para mi gusto, esta vulnerabilidad es mucho más relevante de lo que aparenta a primera vista, y no solo por su impacto:
Aquí está lo que de verdad me llamó la atención. Un único commit de 2023 introdujo dos condiciones de carrera distintas en el código de epoll —unas 2.500 líneas en total—. Ambas resultaron ser fallos críticos que llevan a escalada de privilegios.
La primera la encontró Mythos, el modelo de IA de Anthropic, y se reportó como CVE-2026-43074. Ese resultado es impresionante por sí solo: los bugs de carrera en el kernel tienen fama de ser difíciles de encontrar, y demuestra la capacidad de un modelo de frontera para hallarlos. Un investigador independiente incluso llegó a enviar después un exploit 1-day para ese fallo.
La otra carrera es Bad Epoll, y a Mythos se le escapó. Dado que encontró el primer bug en este pequeño camino de código, es muy probable que examinara la misma zona con profundidad. No podemos saber con certeza por qué falló, pero según el propio autor hay dos factores que lo hicieron especialmente esquivo:
Y no solo fue difícil de encontrar: también costó arreglarlo. El primer parche de los mantenedores no lo corregía del todo, y la solución correcta no llegó hasta dos meses después de reportarse el fallo. Es mucho tiempo para un kernel que suele tratar los problemas de seguridad con urgencia.
Para los curiosos, el resumen a vista de pájaro. Dos de las rutas de cierre de epoll se ejecutan al mismo tiempo y colisionan: una libera un objeto mientras la otra sigue escribiendo en él, y ahí está el use-after-free.
El exploit usa cuatro objetos epoll agrupados en dos pares: uno dispara la carrera y el otro hace de víctima. A partir de ahí convierte una escritura UAF de 8 bytes en un UAF sobre un objeto struct file, y con un ataque cross-cache llega a controlar por completo el contenido de ese fichero. Con ese control, consigue una lectura arbitraria de memoria del kernel a través de /proc/self/fdinfo; finalmente secuestra el flujo de control y ejecuta una cadena ROP para obtener un shell de root. La captura del principio muestra precisamente ese recorrido: race won, cross-cache ok, el hijack de f_op->poll y, al final, uid=0(root).
Aquí es donde aterriza en lo práctico. Los sistemas afectados son los que usan kernels basados en la versión 6.4 o superior y aún no han incorporado la corrección. Los kernels basados en 6.1 no se ven afectados, porque el bug se introdujo en la 6.4.
Ese rango cubre buena parte de la infraestructura moderna: hosts de virtualización, máquinas virtuales, contenedores y, por supuesto, hypervisores recientes. Si operas un cloud privado sobre Proxmox, tus hosts y tus cargas conviven con kernels de esa generación, y el patrón de riesgo es el de siempre en entornos multi-tenant: un proceso sin privilegios dentro de una VM o un contenedor que escala a root convierte un fallo local en un problema de plataforma. Es la misma moraleja estructural que ya contamos con Leaky Vessels en runc: la disciplina de fondo —parcheo al día, mínimo privilegio y radio de explosión acotado— es lo que de verdad te protege del próximo CVE, no de este en concreto.
La comprobación es directa. Mira tu versión de kernel:
uname -rSi estás en la rama 6.4 o superior, aplica las actualizaciones de seguridad de tu distribución. La corrección de fondo es el commit upstream a6dc643c6931; cada distribución lo incorpora como backport en sus paquetes de kernel. Como epoll no se puede desactivar, no hay mitigación alternativa: la única vía es parchear. En Debian/Ubuntu, lo habitual:
apt update && apt full-upgrade
# y reinicia para arrancar con el kernel parcheado
rebootY sí, hay que reiniciar: actualizar el paquete no cambia el kernel que ya está corriendo en memoria.
| Dato | Valor |
|---|---|
| Identificador | CVE-2026-46242 (Bad Epoll) |
| Tipo | Use-after-free por condición de carrera (close-vs-close) |
| Subsistema | epoll (kernel de Linux) |
| Impacto | Escalada local a root; también en Android |
| Introducido | Commit 58c9b016e128 (2023-04-08) |
| Corregido | Commit a6dc643c6931 (2026-04-24) |
| Versiones afectadas | Kernels basados en v6.4+ sin el backport |
| No afectadas | Kernels basados en v6.1 |
| Mitigación | Solo el parche (epoll no se puede desactivar) |
El nombre sigue la serie «Bad» de fallos de kernel que rootean Android —cuyos capítulos previos son Bad Binder, Bad IO_uring y Bad Spin—; Bad Epoll es el equivalente en epoll. Pero más allá de la anécdota, lo que muestra este caso es lo difíciles que son las condiciones de carrera en cada etapa: cuesta encontrarlas incluso para un modelo de frontera, cuesta corregirlas bien y cuesta explotarlas de forma fiable. Y apunta a una dirección de investigación que sigue mereciendo la pena aun con IA de por medio: destapar impacto de seguridad real detrás de condiciones de temporización estrechas y evidencia débil.
Seguiremos atentos, pero mi conclusión es clara: usar la IA para descubrir vulnerabilidades de software es condición necesaria, pero no suficiente para estar a salvo. Creo que el camino es un modelo híbrido, donde la máquina y el criterio humano se complementen. Ya escribí sobre la nueva generación de modelos aplicada a la ciberseguridad y sobre la IA ofensiva como parte de una seguridad continua: la tecnología da resultados excelentes, pero no dejemos de lado nuestro talento tan a la ligera. Combinando ambos mundos sobreviviremos más y, probablemente, nos saldrá hasta más barato. Es la misma filosofía con la que abordamos la ciberseguridad en cada proyecto de cloud privado.
¿Qué es Bad Epoll (CVE-2026-46242)? Un use-after-free por condición de carrera en el subsistema epoll del kernel de Linux. Dos rutas de cierre chocan: una libera un objeto mientras la otra escribe en él, lo que permite a un proceso sin privilegios escalar a root, tanto en Linux como en Android.
¿A qué versiones del kernel afecta?
A los kernels basados en la versión 6.4 o superior que no hayan incorporado el parche. Los basados en 6.1 no están afectados: el bug se introdujo en la 6.4 (commit 58c9b016e128, de abril de 2023) y se corrigió en la a6dc643c6931, de abril de 2026.
¿Puedo mitigarlo sin parchear? No. epoll es una función central del kernel de la que dependen el sistema, la red y los navegadores, y no se puede desactivar. La única solución es aplicar el parche o el backport de tu distribución y reiniciar.
¿Por qué se le pasó a la IA de Mythos? Mythos auditó el mismo código y sí encontró un bug hermano (CVE-2026-43074), pero Bad Epoll se le escapó. Según el autor, por dos motivos: la ventana de carrera es minúscula (unas seis instrucciones) y el use-after-free no dispara KASAN, con lo que faltaba la evidencia en tiempo de ejecución que da confianza para reportarlo.
¿Significa esto que no sirve usar IA para buscar vulnerabilidades? Al contrario. La IA encontró la carrera hermana, que también es difícil. La lección es que la IA es condición necesaria pero no suficiente: lo sensato es un modelo híbrido en el que la revisión automática y el criterio humano se complementen.
Fuentes: repositorio y writeup de Bad Epoll de Jaeyoung Chung en GitHub, el programa Google kernelCTF y los commits del kernel de Linux 58c9b016e128 (introducción) y a6dc643c6931 (corrección). Las capturas provienen del repositorio del descubridor.
IPv4 se ha vuelto un recurso caro y escaso que alguien te alquila. IPv6 devuelve algo que dábamos por perdido: direccionamiento propio, suficiente y sin NAT. Repasamos cómo montar dual-stack en un cloud privado sobre Proxmox, qué gana la operación y qué mitos conviene enterrar antes de migrar.
Un estudio en arXiv mide, vía satélite, un aumento medio de 2,07 ºC en la temperatura de superficie alrededor de los centros de datos. El dato es llamativo, pero conviene leerlo sin convertirlo en eslogan: qué mide realmente, qué no, y por qué el problema de fondo no es el edificio, sino el software poco frugal que ejecutamos dentro.
El streaming del Mundial de la FIFA llevó el tráfico global de interconexión de DE-CIX a un máximo histórico de 28,4 Tbit/s durante el partido Portugal–España. Qué significa ese pico, por qué la demanda de un partido es tan brutal y qué papel juegan los puntos neutros de Internet —Madrid, Lisboa y Barcelona incluidos— en que la retransmisión no se caiga.