Una nueva vulnerabilidad del kernel de Linux, denominada Bad Epoll, puede permitir que un usuario local sin privilegios consiga acceso de superusuario. El problema está registrado como CVE-2026-46242 y afecta al subsistema epoll, utilizado ampliamente por servidores, aplicaciones, navegadores y dispositivos Android.
La vulnerabilidad fue descubierta por el investigador Jaeyoung Chung y presentada como un hallazgo de día cero dentro del programa kernelCTF de Google. El investigador demostró una escalada de privilegios en entornos Linux de prueba y publicó posteriormente el análisis técnico.
Alerta principal: Bad Epoll no permite atacar directamente cualquier servidor desde Internet. Es una vulnerabilidad de escalada local: el atacante primero necesita ejecutar un proceso o disponer de acceso limitado dentro del sistema.
¿Qué es Bad Epoll?
Bad Epoll es el nombre asignado a una condición de carrera y uso de memoria después de haber sido liberada, conocida técnicamente como use-after-free. La falla aparece cuando dos operaciones relacionadas con objetos epoll se ejecutan al mismo tiempo y una estructura del kernel es liberada mientras otra parte del sistema todavía intenta utilizarla.
La descripción oficial de CVE-2026-46242 señala que el problema se encuentra en el mecanismo eventpoll del kernel y afecta el manejo de estructuras relacionadas con ep_remove(). Ubuntu clasifica la vulnerabilidad con prioridad alta y una puntuación CVSS 3.1 de 7.8 sobre 10.
En términos sencillos: un proceso común puede provocar una condición incorrecta en la memoria del kernel. Si logra controlar esa corrupción, podría pasar de una cuenta limitada a controlar completamente el sistema como root.
¿Qué función cumple epoll en Linux?
Epoll es un mecanismo del kernel utilizado para vigilar múltiples archivos, sockets y conexiones de red de forma eficiente. Es fundamental en servidores que deben manejar miles de conexiones simultáneas.
Aplicaciones web, bases de datos, navegadores, plataformas de mensajería y servicios creados con Node.js, Python o Java pueden utilizar epoll directa o indirectamente. No se trata de un módulo opcional que pueda retirarse fácilmente: forma parte de las funciones centrales del kernel Linux.
El investigador señala que no existe un interruptor sencillo para desactivar epoll sin afectar seriamente el sistema. Por ello, la medida correctiva real consiste en instalar un kernel que incluya el parche correspondiente.
Por qué la vulnerabilidad es peligrosa
| Riesgo | Impacto posible |
|---|---|
| Escalada de privilegios | Una cuenta sin privilegios podría llegar a ejecutar acciones como root. |
| Control del servidor | El atacante podría modificar archivos, servicios, usuarios y configuraciones. |
| Riesgo en entornos compartidos | Aumenta la preocupación en servidores multiusuario, CI/CD y plataformas de alojamiento. |
| Posibles cadenas de ataque | Podría combinarse con otra vulnerabilidad que permita ejecutar código inicialmente. |
| Android | Los dispositivos que incorporen código vulnerable en su kernel necesitan una actualización del fabricante. |
El exploit desarrollado para kernelCTF alcanzó una confiabilidad cercana al 99 % en uno de los objetivos Linux probados por el investigador. Sin embargo, este resultado corresponde a entornos concretos y no significa que el mismo código funcione sin cambios en todas las distribuciones o dispositivos.
¿Es un ataque remoto?
No es una vulnerabilidad remota por sí sola. El atacante debe conseguir primero la capacidad de ejecutar código localmente, utilizar una cuenta limitada, comprometer un servicio o escapar de una capa previa de aislamiento.
Esto no reduce completamente el riesgo. En un servidor, una aplicación web vulnerable podría permitir la ejecución inicial de código con una cuenta restringida. Bad Epoll podría utilizarse después como una segunda etapa para intentar obtener privilegios de administrador.
Ejemplo de riesgo: una vulnerabilidad en una aplicación concede acceso como usuario de servicio. Bad Epoll podría convertir ese acceso limitado en control total del sistema si el kernel continúa vulnerable.
Versiones del kernel potencialmente afectadas
Según el análisis publicado por el investigador, la condición vulnerable fue introducida mediante un cambio incorporado al kernel principal en abril de 2023 y corregida mediante el commit a6dc643c6931, integrado el 24 de abril de 2026.
Los kernels derivados de Linux 6.4 o versiones posteriores pueden estar afectados cuando no incluyen el parche o su correspondiente backport. No obstante, el número mostrado por uname -r no es suficiente para decidir si un equipo es vulnerable, porque las distribuciones suelen trasladar correcciones a kernels anteriores sin cambiar su versión principal.
La comprobación correcta: consulta el boletín de seguridad de Ubuntu, Debian, Red Hat, SUSE, Arch Linux, Android o el fabricante de tu dispositivo. No determines el estado únicamente observando si utilizas Linux 6.6, 6.12 o 7.x.
¿Cómo afecta a Android?
Android utiliza el kernel Linux, por lo que los cambios vulnerables pueden llegar a teléfonos y tabletas que incorporen ramas afectadas o backports del código. El investigador informó que logró activar la condición de uso de memoria liberada en un dispositivo Pixel 10 basado en un kernel 6.6 o posterior, aunque el exploit completo de root para Android todavía se encontraba en desarrollo en el momento de la publicación.
Esto obliga a interpretar con cuidado algunos titulares: la vulnerabilidad alcanza al ecosistema Android, pero la explotación demostrada públicamente y completa se centró inicialmente en los objetivos Linux de kernelCTF.
GrapheneOS ya informó que incorporó correcciones para CVE-2026-46242 en ramas de kernel 6.1, 6.6 y 6.12. Este caso también demuestra que una rama con número 6.1 puede contener código trasladado desde versiones posteriores, por lo que el estado real depende de cada fabricante y de sus backports.
Usuarios de Android: no descarguen supuestas aplicaciones que prometen “detectar Bad Epoll” o “proteger el kernel”. La corrección debe llegar mediante una actualización legítima del sistema operativo o del fabricante.
Cómo comprobar el kernel instalado en Linux
Para consultar la versión que está ejecutando actualmente el sistema:
En distribuciones basadas en Debian o Ubuntu también puedes consultar los paquetes del kernel instalados:
Estos comandos identifican el kernel, pero no sustituyen la revisión del aviso de seguridad publicado por la distribución.
Cómo corregir Bad Epoll en Linux
La recomendación principal es instalar todas las actualizaciones de seguridad disponibles y reiniciar el equipo para comenzar a utilizar el kernel corregido.
Ubuntu, Debian y Linux Mint
Fedora, AlmaLinux, Rocky Linux y Red Hat
Arch Linux, Manjaro y CachyOS
Después del reinicio, comprueba nuevamente el kernel activo:
Debian, por ejemplo, registra la corrección de CVE-2026-46242 en versiones actualizadas de sus paquetes de kernel. Las versiones exactas cambian según la rama y el repositorio de seguridad, por lo que debe utilizarse el gestor de actualizaciones oficial.
Cómo actualizar un dispositivo Android
- Abre la aplicación Ajustes.
- Selecciona Sistema.
- Entra en Actualización de software o Actualizaciones del sistema.
- Instala las actualizaciones disponibles.
- Reinicia el teléfono cuando sea solicitado.
- En Acerca del teléfono > Versión de Android, revisa el nivel del parche de seguridad.
Google aclara que la disponibilidad de actualizaciones depende del modelo, fabricante y operador móvil. Un dispositivo antiguo que ya no recibe parches puede permanecer expuesto a vulnerabilidades del kernel aunque las correcciones existan públicamente.
Medidas temporales para reducir el riesgo
No existe una solución alternativa que neutralice completamente Bad Epoll sin actualizar el kernel. Mientras se programa la instalación del parche, una empresa puede reducir la exposición mediante controles complementarios.
- Restringir el acceso SSH a usuarios realmente necesarios.
- Eliminar cuentas antiguas o sin uso.
- Aplicar autenticación multifactor donde esté disponible.
- Reducir la ejecución de aplicaciones no confiables.
- Revisar procesos, sesiones y cambios de privilegios.
- Separar cargas críticas mediante máquinas virtuales correctamente configuradas.
- Priorizar servidores multiusuario, plataformas CI/CD y equipos expuestos.
- Programar el reinicio necesario después de instalar el nuevo kernel.
¿Cómo saber si el parche realmente está activo?
Instalar paquetes no siempre significa que el sistema ya está protegido. Si el equipo continúa ejecutando el kernel antiguo, la corrección no entra en funcionamiento hasta después del reinicio.
- Instala las actualizaciones oficiales.
- Reinicia el equipo.
- Ejecuta uname -r.
- Compara el paquete activo con el boletín de tu distribución.
- Verifica que no existan servidores pendientes de reinicio.
En entornos empresariales también conviene registrar el CVE en la plataforma de gestión de vulnerabilidades, asociarlo con los activos afectados y conservar evidencia de la actualización y el reinicio.
Bad Epoll y la inteligencia artificial Mythos
El caso también llamó la atención porque una herramienta de inteligencia artificial de Anthropic, denominada Mythos, había encontrado previamente otra condición de carrera en la misma zona del código epoll.
Según el investigador, el cambio introducido en 2023 generó dos problemas diferentes. Mythos identificó uno de ellos, posteriormente asociado con CVE-2026-43074, pero no detectó la condición que terminó siendo denominada Bad Epoll.
El episodio demuestra que la IA puede ayudar a revisar código complejo, pero todavía necesita validación humana. Las condiciones de carrera son especialmente difíciles porque dependen del orden exacto y del momento en que se ejecutan varios procesos.
Preguntas clave
¿Qué es CVE-2026-46242?
Es una vulnerabilidad de uso de memoria después de liberarla y condición de carrera en el subsistema eventpoll del kernel Linux.
¿Bad Epoll permite atacar un servidor directamente desde Internet?
No por sí sola. El atacante necesita ejecutar código o tener algún nivel de acceso local antes de intentar escalar privilegios.
¿Qué privilegios podría conseguir un atacante?
En sistemas explotables podría conseguir privilegios de root, equivalentes al control administrativo completo del sistema Linux.
¿Todos los kernels Linux 6.4 o superiores son vulnerables?
No necesariamente. Una distribución puede haber incorporado el parche mediante un backport. Debes revisar el aviso oficial del proveedor.
¿Los kernels Linux 6.1 están siempre protegidos?
No se debe asumir. Aunque el error apareció originalmente en código integrado después de Linux 6.1, algunos proveedores pueden trasladar funciones de versiones nuevas a ramas anteriores.
¿Android está afectado?
Puede estarlo cuando el kernel del dispositivo incorpora el código vulnerable. La afectación concreta depende del modelo, versión, parches y cambios aplicados por el fabricante.
¿Existe una aplicación que pueda proteger Android?
No. La corrección debe aplicarse mediante una actualización del sistema y del kernel proporcionada por el fabricante o el proyecto que mantiene el dispositivo.
¿La actualización requiere reiniciar Linux?
Normalmente sí. El nuevo paquete puede quedar instalado, pero el equipo seguirá ejecutando el kernel anterior hasta que se reinicie.
Recomendamos
En resumen
Bad Epoll es una vulnerabilidad importante de escalada local de privilegios en el kernel Linux. Está identificada como CVE-2026-46242, afecta el mecanismo epoll y puede permitir que un proceso sin privilegios alcance control de root en sistemas vulnerables.
El riesgo se extiende potencialmente a servidores, computadoras de escritorio, plataformas compartidas y dispositivos Android que incorporen el código afectado. No obstante, no todos los kernels con el mismo número de versión tienen el mismo estado de seguridad.
La medida efectiva es instalar el kernel corregido distribuido por el proveedor y reiniciar el sistema. En Android, los usuarios deben comprobar periódicamente las actualizaciones del fabricante y evitar herramientas no oficiales que prometan solucionar el problema.
Conclusión editorial
Bad Epoll demuestra que una vulnerabilidad local puede convertirse en un problema crítico cuando se combina con otro acceso inicial. Las empresas no deberían esperar a que aparezcan ataques masivos: deben actualizar, reiniciar, verificar el kernel activo y mantener un inventario claro de todos sus sistemas Linux y Android.
