Un investigador de seguridad ha publicado un exploit funcional y extremadamente fiable para una vulnerabilidad del kernel de Linux que permite a un usuario normal, sin privilegios, tomar el control total de una máquina como root - sin contraseña, sin ingeniería social, solo con ejecución de código local. El fallo, de tipo Local Privilege Escalation (LPE), registrado como CVE-2026-46242 y apodado "Bad Epoll", afecta a servidores y equipos de escritorio Linux, así como a teléfonos Android con kernel 6.4 o superior. Ya existe un parche en el kernel principal, pero todavía no se ha desplegado de forma generalizada.
Cómo funciona el use-after-free de Bad Epoll
El fallo reside en epoll, el mecanismo que usa el kernel de Linux para permitir que un solo programa vigile miles de archivos abiertos o conexiones de red a la vez - algo de lo que dependen prácticamente todos los servidores web, bases de datos y demonios VPN. El investigador Jaeyoung Chung, del Computer Security Lab de la Universidad Nacional de Seúl, descubrió que cuando dos rutinas internas de limpieza de epoll, dentro de la función ep_remove(), se ejecutan al mismo tiempo, una puede liberar un bloque de memoria del kernel mientras la otra todavía está escribiendo en él. Esa ventana de use-after-free tiene un ancho de apenas seis instrucciones de CPU, pero la prueba de concepto de Chung, ya pública en GitHub, aprovecha la memoria corrupta para construir una cadena de programación orientada al retorno (ROP) que secuestra el flujo de ejecución del kernel y otorga root al atacante.
Quién está expuesto
- Servidores y equipos de escritorio Linux: cualquier distribución con un kernel principal a partir de la versión 6.4 es vulnerable.
- Dispositivos Android: se ha confirmado que funciona en un Google Pixel 10 (kernel 6.6); los dispositivos más antiguos que siguen en la rama de soporte a largo plazo 6.1 no están afectados.
- El navegador como puerta de entrada: como el exploit solo necesita ejecución de código local, los investigadores señalan que en teoría podría lanzarse desde dentro de un proceso aislado como el renderizador de Chrome, convirtiendo un simple fallo del navegador en la toma total del dispositivo.
El primer intento de solución de los mantenedores del kernel, publicado tras corregir un fallo relacionado anterior (CVE-2026-43074), no cerró del todo el problema - hicieron falta unos dos meses más antes de que un parche correcto llegara al kernel principal. Ese proceso de parcheo lento y en dos etapas explica precisamente por qué tantos sistemas siguen expuestos: las distribuciones y los fabricantes de Android suelen ir varios ciclos de parches por detrás del kernel principal, y los servidores autogestionados aún más.
Cómo comprobar si estás afectado
Ejecuta uname -r en una terminal para ver la versión de tu kernel. Si indica 6.4 o superior y tu distribución o dispositivo no ha recibido una actualización de seguridad desde principios de julio de 2026, considera el sistema vulnerable y aplica cuanto antes el último parche del kernel o del fabricante.
Por qué esto va más allá de los ordenadores personales
Bad Epoll no necesita conexión de red para funcionar - solo ejecución de código local, lo que a primera vista suena tranquilizador. Pero hoy "local" abarca mucho terreno: servidores de alojamiento compartido, runners de CI/CD, instancias VPS en la nube, dispositivos de red autogestionados y cualquier máquina Linux que en algún momento ejecute código no confiable, ya sea un script descargado, un escape de contenedor o una pestaña del navegador comprometida. En cuanto un atacante consigue el más mínimo punto de apoyo, Bad Epoll lo convierte en control administrativo completo.
Un patrón más amplio
Bad Epoll también recuerda cuánto depende la infraestructura de red moderna - incluidas las máquinas Linux que ejecutan pasarelas VPN, proxies autogestionados y routers domésticos - de un subsistema del kernel del que la mayoría de los usuarios nunca ha oído hablar. Una sola máquina sin parchear en una red compartida, o un proveedor de VPN lento en desplegar actualizaciones de kernel en su flota de servidores, puede convertir un fallo "puramente local" en una exposición mucho mayor para todos los que enrutan su tráfico por ahí. Esta historia continúa una tendencia que se repite este año: desde el robo de credenciales de FortiGate hasta Citrix Bleed, el eslabón más débil de la infraestructura de privacidad resulta ser una y otra vez código de kernel y firmware sin parchear y de aspecto poco llamativo, y no el propio cifrado.
