Un fallo del kernel de Linux recién divulgado, llamado Bad Epoll (CVE-2026-46242), permite que cualquier usuario común de una máquina escale hasta obtener acceso root completo, y afecta a servidores, equipos de escritorio y dispositivos Android con Linux que ejecuten el kernel 6.4 o posterior. Se publicó el 3 de julio de 2026, después de que el investigador Jaeyoung Chung presentara un exploit funcional al programa kernelCTF de Google. Ya hay una corrección en el kernel principal, pero la mayoría de las distribuciones todavía tienen que publicar un backport, así que la tarea práctica ahora mismo es comprobar tu versión del kernel y aplicar la actualización de seguridad de tu distribución en cuanto esté disponible.
Hay una buena noticia por adelantado: al momento de escribir esto, el fallo no figura en el catálogo de vulnerabilidades explotadas conocidas de CISA, y el único exploit funcional es la prueba de concepto del concurso. Eso te da un margen para parchear antes de que aparezca en cadenas de ataque reales.
¿Qué es Bad Epoll y por qué otorga acceso root?
Bad Epoll es un uso después de liberar (use-after-free) provocado por una condición de carrera en el subsistema epoll del kernel, el mecanismo que Linux usa para vigilar a la vez grandes cantidades de archivos y sockets de red. Dos partes del kernel intentan liberar el mismo objeto interno al mismo tiempo: un hilo libera la memoria mientras otro todavía está escribiendo en ella. Ese solapamiento permite que un atacante corrompa la memoria del kernel de forma controlada y reescriba las credenciales de su propio proceso hasta que el kernel lo trate como root.
Lo que hace notable el fallo es lo estrecha que es la oportunidad. La ventana de carrera explotable es de unas seis instrucciones máquina de ancho, un lapso de tiempo tan pequeño que resulta difícil de acertar incluso cuando puedes leer el código vulnerable. Esa dificultad es la razón por la que nadie lo detectó durante más de dos años, y también por la que un exploit fiable es lo bastante impresionante como para ganar un pago de kernelCTF. Sin embargo, eso no te mantiene a salvo: una vez que alguien escribe el exploit, la ventana de seis instrucciones deja de ser tu protección.
¿Qué versiones del kernel están afectadas?
El fallo se introdujo mediante un cambio en el código de epoll en 2023 y llegó con Linux 6.4. Todo lo que va de 6.4 a la línea actual sin la corrección está expuesto; los kernels más antiguos basados en la serie 6.1 nunca tuvieron el código problemático y no están afectados. La corrección es el commit del kernel principal a6dc643c6931, incorporado en abril de 2026, y cada distribución lo backportea según su propio calendario.
| Línea del kernel | ¿Afectada? | Qué hacer |
|---|---|---|
| 6.1 LTS y anteriores | No | El fallo es anterior a estas; ninguna acción para esta CVE |
| 6.4 – actual (sin parchear) | Sí | Actualiza a la compilación parcheada de tu distribución y luego reinicia |
Cualquier compilación con el commit a6dc643c6931 | No | Ya corregido; confírmalo y sigue adelante |
| Android en kernels 6.4+ | Sí | Espera la actualización de seguridad del dispositivo o fabricante |
Ten en cuenta que Android entra en el alcance cuando el dispositivo incluye un kernel 6.4 o posterior; el hardware que sigue en 6.1, como algunos teléfonos existentes, no está afectado. En los servidores, el riesgo sigue al kernel, no al nombre de la distribución, así que una distribución LTS «estable» puede seguir ejecutando un kernel 6.x afectado.
Cómo comprobar y parchear tus propios servidores
Empieza leyendo la versión del kernel en ejecución y compárala con el aviso de tu distribución. En cualquier máquina Linux:
uname -r # p. ej. 6.8.0-40-generic — 6.4+ significa buscar el parche
apt list --upgradable 2>/dev/null | grep -i linux # Debian/Ubuntu
dnf updateinfo list security | grep -i kernel # familia Fedora/RHEL
Luego aplica la actualización de seguridad y reinicia en el nuevo kernel. Un paquete de kernel parcheado no hace nada hasta que reinicias realmente sobre él, que es el paso que la gente se salta. Si no puedes asumir un tiempo de inactividad de inmediato, un servicio de parcheo en vivo (kernel livepatch en Ubuntu, kpatch en RHEL) puede cerrar el agujero sin reiniciar en kernels compatibles, ganándote tiempo hasta una ventana de mantenimiento. Vigila el canal de seguridad de tu distribución —los USN de Ubuntu, el rastreador de seguridad de Debian o el feed de avisos de tu fabricante— en busca de la entrada de CVE-2026-46242, ya que la corrección del kernel principal y el backport empaquetado llegan en días distintos.
Por qué un fallo «solo local» sigue importando para un único VPS
Es tentador encogerse de hombros ante un fallo de escalada de privilegios local: un atacante necesita estar ya en la máquina, así que si nadie tiene una shell, no hay nada que escalar. Ese razonamiento se cae en la práctica. El acceso root local es la segunda etapa de la mayoría de las intrusiones reales. Una aplicación web con un fallo de ejecución remota de código, una clave de despliegue filtrada, una dependencia envenenada o un contenedor comprometido dan todos al atacante algo de ejecución de código como usuario sin privilegios. Bad Epoll es lo que convierte ese punto de apoyo en control total del host, incluida cualquier otra aplicación y base de datos en la misma máquina.
Esa es exactamente la forma del riesgo en un VPS autogestionado, donde tu aplicación, tu base de datos y tu plano de control suelen compartir un mismo kernel. Si gestionas tu propio servidor, este fallo pertenece a la misma lista de comprobación de fortalecimiento que las claves SSH y un cortafuegos: lo básico que repasamos en nuestra guía para autoalojar tus aplicaciones en un VPS. También es un recordatorio de que las defensas perimetrales no bastan por sí solas; los controles por capas como el modelo de confianza cero asumen que una brecha ocurrirá y limitan lo que puede alcanzar una sola cuenta comprometida.
¿Se está explotando Bad Epoll de forma activa?
Todavía no. No hay indicios de uso en el mundo real, la vulnerabilidad no figura en la lista KEV de CISA y el único exploit público es el enviado a kernelCTF. Pero «aún sin explotación» es un calendario, no un veredicto. Los LPE públicos del kernel se convierten rutinariamente en armas una vez que investigadores o atacantes reconstruyen la técnica, y los detalles ya están al descubierto. La suposición segura es que circulará un exploit funcional, así que trata el parche como algo urgente y no opcional. Este patrón —un fallo de rápido movimiento contra el que los defensores tienen que correr— se está convirtiendo en la norma a medida que los atacantes automatizan más el trabajo, una tendencia que tratamos en la seguridad de los agentes de IA y la crisis de la inyección de prompts.
Preguntas frecuentes
¿Tengo que reiniciar después de parchear Bad Epoll?
Sí, salvo que uses parcheo en vivo del kernel. Instalar el paquete de kernel actualizado prepara la corrección, pero el código vulnerable sigue ejecutándose hasta que arrancas en el nuevo kernel. Livepatch (Ubuntu) o kpatch (RHEL) pueden aplicar la corrección a un kernel en ejecución en versiones compatibles si no puedes reiniciar de inmediato.
¿Está afectado mi servidor si ejecuta una distribución LTS?
Posiblemente. Lo que importa es la versión del kernel, no el marketing de la distribución. Una versión LTS puede incluir igualmente un kernel 6.4 o posterior, que es el rango afectado. Ejecuta uname -r y consulta el aviso de tu distribución sobre CVE-2026-46242.
¿Corren riesgo los teléfonos Android?
Solo los que tengan un kernel 6.4 o posterior. Los dispositivos que siguen en kernels basados en 6.1, incluidos algunos teléfonos actuales, no están afectados. Cuando un dispositivo entra en el rango, espera e instala la actualización de seguridad del fabricante.
¿Qué gravedad tiene esto comparado con un exploit remoto?
Por sí solo, un fallo local necesita que un atacante ya tenga un punto de apoyo, por lo que se sitúa por debajo de un fallo de ejecución remota de código. En la práctica es el paso siguiente habitual tras una brecha inicial, y por eso los fallos de root locales son codiciados y por eso parchear con prontitud sigue importando.
Fuentes
- The Hacker News — New "Bad Epoll" Linux Kernel Flaw Lets Unprivileged Users Gain Root: información primaria sobre CVE-2026-46242, la causa raíz del use-after-free en epoll, la ventana de carrera de unas seis instrucciones, los kernels 6.4+ afectados, el commit de corrección
a6dc643c6931, el descubrimiento por Jaeyoung Chung a través de Google kernelCTF y la ausencia de uso en el mundo real. - CISA Known Exploited Vulnerabilities Catalog: referencia para confirmar si CVE-2026-46242 se ha añadido como vulnerabilidad explotada de forma activa.
- bad-epoll proof-of-concept repository: el código público del exploit de kernelCTF que demuestra la escalada de privilegios.
Waqas Ahmed Waseer
Waqas Ahmed Waseer es desarrollador y creador de automatizaciones con más de 8 años construyendo sistemas en producción que usan más de 100.000 personas. Crea SaaS multiinquilino a medida, automatización con IA (n8n, flujos LLM, bots de WhatsApp) e infraestructura de hosting (WHM/cPanel, CloudLinux), y es el creador de WaSphere, FlowMaticX y la marca de hosting WaseerHost. Más de 100 proyectos entregados para pymes, agencias y startups financiadas.
