Bad Epoll (CVE-2026-46242): root en tu Cloud Server Linux

Si tenés un Cloud Server Linux donde corre más de un usuario —o donde un proceso poco privilegiado puede ejecutar código (un contenedor, un runner de CI, una app web con RCE potencial)—, Bad Epoll te pega de lleno. Se trata de CVE-2026-46242, una falla de tipo use-after-free en el subsistema epoll del kernel que permite que cualquier usuario local sin privilegios escale a root. Ya hay prueba de concepto pública, la explotación funciona el 99% de las veces, y lo más incómodo: no existe una mitigación por configuración. La única salida es parchear.

Bad Epoll (CVE-2026-46242) es una vulnerabilidad de escalada de privilegios local en el kernel de Linux. Es una condición de carrera use-after-free en epoll, el mecanismo de notificación de eventos de E/S que usan nginx, Node.js, Python asyncio, bases de datos y hasta Android. Un usuario local corriente puede corromper memoria del kernel y obtener ejecución de código con privilegios de root. Tiene CVSS 7.8 y afecta servidores, escritorios y dispositivos Android.

¿Por qué un bug en epoll golpea a casi cualquier servidor Linux?

epoll no es una pieza exótica: es el corazón del modelo de E/S asincrónica de Linux. Cuando un servidor tiene que vigilar miles de conexiones a la vez sin bloquear un hilo por cada una, usa epoll_create, epoll_ctl y epoll_wait. Por eso está presente, de forma directa o indirecta, en prácticamente todo lo que corre en un Cloud Server de producción:

• Servidores web y reverse proxies. nginx y Apache event MPM se apoyan en epoll para manejar concurrencia.
• Runtimes y lenguajes. El event loop de Node.js (libuv), asyncio de Python y muchos otros lo usan por debajo.
• Bases de datos y colas. Motores que multiplexan sockets sobre epoll.
• Android. Su infraestructura de event loop también lo utiliza, por eso el fallo llega hasta dispositivos móviles.

La consecuencia práctica es que el código vulnerable está siempre cargado y no se puede apagar. No hay un "deshabilitá este módulo" que te saque del problema sin romper el sistema operativo entero.

¿Qué versiones del kernel afecta CVE-2026-46242?

Acá está la primera trampa. El repositorio del PoC describe como afectada la rama mainline v6.4 y posteriores. Pero eso solo vale para el kernel de línea principal: los proveedores de distribuciones backportean el commit que introdujo el bug (de 2023) a ramas mucho más viejas, así que verte "por debajo de 6.4" no te salva.

• Mainline: vulnerable desde v6.4 en adelante, salvo que ya traiga el fix upstream.
• Kernels enterprise: ramas basadas en 5.14 o 6.12 aparecen como afectadas por el backport del commit original; se reportó impacto tan atrás como 5.10 en algunos análisis.
• Android: confirmado en dispositivos Pixel 10 sobre kernel 6.6.
• Aparentemente a salvo: algunas ramas LTS basadas en 6.1 que no recibieron el commit introductor.

Moraleja: no confíes en la tabla de versiones a ojo. Verificá si tu kernel tiene el fix (más abajo te muestro cómo).

¿Cómo funciona el fallo a nivel técnico?

Bad Epoll es una condición de carrera close-vs-close en la ruta de liberación de archivos de epoll. El detalle está en ep_remove(): la función limpia file->f_ep bajo file->f_lock, pero sigue usando el objeto file dentro de la sección crítica, durante hlist_del_rcu() y spin_unlock().

El problema aparece cuando un __fput() concurrente observa ese valor transitorio en NULL, se saltea eventpoll_release_file() y avanza directo a f_op->release. Eso libera una struct eventpoll que todavía está en uso: memoria del kernel corrompida, y a partir de ahí un atacante encadena una fuga de memoria y un secuestro de una llamada indirecta para controlar el instruction pointer. El PoC lo convierte en root con una cadena ROP (Return-Oriented Programming).

Lo notable de la ingeniería del exploit es la ventana temporal: la carrera vive en un margen de apenas seis instrucciones de CPU, y aun así el investigador logró una tasa de éxito cercana al 99%. No es un bug "teórico" difícil de disparar.

El dato que importa: una IA encontró el bug hermano (CVE-2026-43074)

Bad Epoll no vino solo. Un único commit de 2023 introdujo dos condiciones de carrera separadas en apenas ~2.500 líneas del código de epoll, y las dos resultaron ser bugs críticos de escalada de privilegios. El primero fue reportado como CVE-2026-43074 y lo encontró Mythos, el sistema de auditoría de código con IA de Anthropic. El segundo —Bad Epoll— lo halló el investigador Jaeyoung Chung, que lo envió como 0-day al programa Google kernelCTF (que paga recompensas de US$71.337 y más por exploits de kernel).

La lectura para cualquiera que administra infraestructura: el mismo puñado de líneas escondía dos vulnerabilidades explotables durante años, una encontrada por auditoría con IA y otra por un humano. Que un revisor automático haya pasado por al lado de Bad Epoll es un recordatorio de que ninguna herramienta —ni humana ni de IA— reemplaza a parchear rápido.

¿Qué implica Bad Epoll para un Cloud Server en producción?

Bad Epoll es de escalada local: el atacante ya necesita poder ejecutar código en tu servidor. Eso no lo hace menos grave, porque en un servidor real ese "punto de apoyo" inicial es más común de lo que parece:

• Servidores multiusuario o compartidos. Cualquier cuenta de bajo privilegio se transforma en root.
• Escape de contenedores. Un proceso que rompe el aislamiento de un contenedor y llega al kernel del host puede usar este bug para adueñarse de la máquina.
• Segunda etapa de un ataque web. Una RCE en tu app (que corre como www-data o similar) normalmente queda "contenida" en ese usuario; con Bad Epoll, se vuelve root del sistema.
• Runners de CI/CD. Cualquier job que ejecuta código de terceros en tu infraestructura es un vector directo.

Al momento de escribir esto no hay evidencia de explotación activa en la naturaleza, pero el PoC ya es público. La distancia entre "prueba de concepto" y "exploit usándose en masa" suele medirse en días.

¿Cómo sé si mi Cloud Server es vulnerable?

Primero, mirá tu kernel:

uname -r

Como ya vimos, el número de versión solo no alcanza (los vendors backportean cambios). La forma confiable es chequear si tu ep_remove() ya trae el fix, que "pinea" la referencia al archivo antes de tocar file->f_lock. Según el análisis de TuxCare, podés inspeccionar el fuente del kernel instalado:

grep -n 'epi_fget\|__free(fput)' /usr/src/kernels/$(uname -r)/fs/eventpoll.c

Si ep_remove() pinea el archivo con epi_fget() y un guard __free(fput) antes de tocar file->f_lock, el parche está presente. Si no tenés los fuentes instalados, apoyate en el tracking de tu distribución: consultá el aviso de seguridad de tu proveedor con el ID CVE-2026-46242.

¿Cómo lo mitigo hoy?

No hay vueltas: epoll no se puede desactivar sin romper el SO, no hay sysctl que tocar ni módulo que blacklistear. La mitigación es una sola —parchear— más algunas medidas de contención mientras el parche llega:

• Verificá que arrancaste con el kernel parcheado. Después del reboot, volvé a correr uname -r y confirmá contra el aviso de tu distro. Actualizar el paquete pero no reiniciar te deja corriendo el kernel viejo y vulnerable.
• Reducí quién puede ejecutar código en el host. Menos cuentas locales, menos jobs de terceros, contenedores con menos privilegios: achicás la superficie mientras validás el fix.
• Aislá lo no confiable. Separá cargas de trabajo de terceros del host que te importa; no las corras junto a servicios sensibles.
• Si usás livepatching, tené en cuenta que al momento de este análisis el parche en vivo todavía estaba en validación en algunos proveedores; no lo des por hecho, confirmá que esté disponible en tu feed.

Actualizá el kernel y reiniciá. En una base Debian/Ubuntu, aplicá updates y bootéa al kernel nuevo:

sudo apt update && sudo apt full-upgrade
sudo reboot

Si venís siguiendo estos temas, esto se conecta con nuestra nota sobre DirtyClone (CVE-2026-43503), otra escalada a root reciente en Ubuntu/Debian/Fedora, y con la guía de hardening inicial de un Cloud Server Ubuntu (SSH, UFW y Fail2Ban): reducir la superficie de acceso es justamente lo que te da aire cuando aparece un 0-day de kernel como este.

Preguntas frecuentes

¿Bad Epoll se puede explotar de forma remota?

No directamente. Es una escalada de privilegios local: el atacante ya tiene que poder ejecutar código en el servidor. El riesgo real es que se combine con un acceso inicial —una cuenta de bajo privilegio, un escape de contenedor o una RCE en una app— para pasar a root.

¿Qué versión del kernel corrige CVE-2026-46242?

El fix correcto pinea la referencia al archivo dentro de ep_remove(). En lugar de fiarte de un número de versión, verificá que tu kernel incluya ese cambio (con el grep de arriba) o consultá el aviso de seguridad de tu distribución para el ID CVE-2026-46242, porque cada distro lo backportea a sus propias ramas.

¿Hay alguna forma de mitigarlo sin parchear?

No hay una mitigación por configuración. epoll es parte central del kernel y no se puede desactivar ni bloquear con un sysctl. Lo único que baja el riesgo mientras parcheás es reducir y aislar quién puede ejecutar código en el host.

¿Ya se está explotando en ataques reales?

Al momento de esta nota no hay evidencia de explotación en la naturaleza, pero la prueba de concepto es pública y logra root en cerca del 99% de los intentos. Tratalo como urgente.

¿Es cierto que una IA descubrió parte de esto?

Sí, pero no exactamente Bad Epoll. El mismo commit de 2023 introdujo dos bugs; el "hermano", CVE-2026-43074, lo encontró el auditor con IA Mythos de Anthropic. Bad Epoll (CVE-2026-46242) lo halló el investigador Jaeyoung Chung y lo reportó vía Google kernelCTF.

Conclusión

Bad Epoll es el tipo de vulnerabilidad que no te pide nada raro para hacer daño: un usuario local cualquiera, una ventana de seis instrucciones y un exploit que funciona casi siempre. Como epoll no se puede apagar, la respuesta es aburrida pero contundente: actualizá el kernel, reiniciá y confirmá que arrancaste con el fix. Y aprovechá para revisar cuánta gente y cuánto código de terceros puede, hoy, ejecutar algo en tus servidores.

Fuentes: The Hacker News, SecurityWeek, Security Affairs y TuxCare.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting