CVE-2026-46242: Vulnerabilidad «Bad Epoll» permite escalar privilegios a root en Linux y Android

Introducción

En enero de 2026, el investigador de seguridad Jaeyoung Chung descubrió una vulnerabilidad crítica en el subsistema epoll del kernel de Linux, apodada «Bad Epoll» (CVE-2026-46242), que permite a un usuario local sin privilegios elevados escalar privilegios hasta obtener acceso root. El exploit desarrollado por Chung logra explotar esta condición de use-after-free con una tasa de éxito del 99% en sistemas de prueba, lo que lo convierte en un vector de ataque altamente confiable. Aunque aún no hay evidencia de explotación en entornos productivos, la combinación de su facilidad de explotación y su impacto en múltiples plataformas lo posiciona como una amenaza crítica para infraestructuras basadas en Linux y dispositivos Android.

Lo más preocupante no es solo el fallo en sí, sino el contexto en el que se descubrió: el mismo segmento de código del kernel de Linux ya había sido analizado por el modelo de IA Mythos de Anthropic, que identificó otro bug similar (CVE-2026-43074) pero pasó por alto a Bad Epoll. Esto subraya un problema fundamental: incluso los sistemas de detección automatizada más avanzados pueden omitir vulnerabilidades críticas, especialmente en condiciones de carrera (race conditions), donde la ventana de explotación es extremadamente estrecha.

Qué ocurrió

El exploit funciona incluso desde el sandbox de Chrome, un entorno altamente restringido diseñado para bloquear la mayoría de los exploits de kernel. Además, a diferencia de muchos fallos de escalada de privilegios en Linux, Bad Epoll también afecta a Android, lo que amplía su superficie de ataque a dispositivos móviles. El investigador presentó el fallo como zero-day al programa kernelCTF de Google y desarrolló un proof-of-concept público, aunque aún no se ha reportado explotación en el mundo real. Según Chung, el desarrollo de un exploit para Android aún está en progreso.

El fallo se remonta a un cambio introducido en 2023 en el código de epoll, que también fue analizado por el modelo Mythos de Anthropic. Este modelo había identificado previamente otro bug en la misma área del código (CVE-2026-43074), que ya fue parcheado en versiones tempranas de 2026. Sin embargo, Mythos no detectó Bad Epoll, lo que sugiere que los fallos de tipo race condition siguen siendo extremadamente difíciles de detectar, incluso para sistemas de IA avanzados.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y administración de sistemas

Para equipos de DevOps y administración de sistemas, Bad Epoll representa un riesgo crítico porque:

• Afecta a kernels recientes: Todos los kernels basados en versiones 6.4 o superiores de Linux están vulnerables, a menos que ya tengan el parche aplicado. Esto incluye la mayoría de las distribuciones modernas (Ubuntu 24.04, RHEL 10, Debian 13, etc.).
• No hay workaround: El subsistema epoll es fundamental para el funcionamiento de servidores web, bases de datos, contenedores y navegadores. No puede desactivarse sin romper funcionalidades críticas.
• Explotación silenciosa: El fallo no suele activar las herramientas de detección como KASAN (Kernel Address Sanitizer), lo que dificulta su identificación en entornos de producción.

Cloud y entornos escalables

En entornos cloud como AWS, AKS o GKE, la vulnerabilidad es especialmente relevante porque:

• Kernels afectados en servicios gestionados: Muchos proveedores de cloud aún no han aplicado el parche en sus imágenes de kernel predeterminadas. Por ejemplo, en AWS EKS, los nodos basados en Amazon Linux 2023 (kernel 6.1) no están afectados, pero los nodos con kernel 6.4+ sí lo están.
• Riesgo en contenedores: Aunque los contenedores suelen correr con menos privilegios, un exploit exitoso en el host puede comprometer todo el clúster. Además, el fallo en el código de epoll afecta a servicios como Kubernetes, Docker y servidores web (Nginx, Apache).
• Exposición en servicios compartidos: En entornos multiinquilino como cloud público, un atacante con acceso a una máquina virtual o contenedor podría escalar privilegios y comprometer otros inquilinos.

Seguridad y equipos de respuesta

Para los equipos de seguridad, Bad Epoll es un recordatorio de que:

• Las vulnerabilidades de tipo race condition siguen siendo un desafío: Aunque los modelos de IA como Mythos pueden detectar fallos complejos, los problemas de sincronización siguen siendo difíciles de identificar, incluso para sistemas automatizados.
• La explotación es determinista: A diferencia de otros fallos que requieren condiciones específicas, Bad Epoll tiene una tasa de éxito del 99% en sistemas de prueba, lo que lo hace altamente predecible y reproducible.
• Impacto en Android: Aunque el exploit para Android aún no está disponible públicamente, la vulnerabilidad afecta a dispositivos con kernels 6.4+, incluyendo modelos recientes como Pixel 8 y 9. Esto abre la puerta a ataques en dispositivos móviles, especialmente en entornos empresariales donde los empleados usan sus dispositivos personales (BYOD).

Detalles técnicos

Mecanismo de explotación

1. Hilo A (ep_free()): Libera la memoria asociada a un epitem.
2. Hilo B (ep_remove()): Intenta acceder a la misma estructura de datos después de que ya fue liberada.

Si estos dos hilos se ejecutan de manera casi simultánea, el Hilo B puede corromper la memoria liberada, lo que permite a un atacante escribir datos arbitrarios en el kernel y escalar privilegios. La ventana crítica para explotar este fallo es de solo seis instrucciones de máquina, lo que hace que sea extremadamente difícil de detectar y explotar sin un método específico.

Chung desarrolló un exploit que amplía esta ventana mediante:

• Técnicas de spraying de memoria: Asignar múltiples objetos epitem para aumentar las probabilidades de que el fallo ocurra.
• Retries controlados: Repetir el ataque hasta lograr la explotación exitosa, sin causar un crash en el sistema.

Versiones afectadas

• Subsistema epoll: Usado por servidores web (Nginx, Apache), bases de datos (PostgreSQL, MySQL), navegadores (Chrome, Firefox) y contenedores (Docker, Kubernetes).
• Sistemas Android: Kernels 6.4+ en dispositivos con versiones recientes de Android (14 y 15).
• Entornos cloud: Kernels personalizados en servicios como AWS EKS, AKS y GKE que usan versiones 6.4+.

Comparación con otros fallos recientes

• CVE-2026-31431 («Copy Fail»): Fallo de page cache explotado en el mundo real (incluido en la lista Known Exploited Vulnerabilities de CISA).
• CVE-2026-31694: Fallo en el sistema de archivos FUSE que permite corrupción de memoria y escalada de privilegios en contenedores y servidores.
• CVE-2026-43074: Otro fallo en epoll detectado por Mythos y parcheado previamente.

A diferencia de fallos como Dirty Pipe (CVE-2022-0847) o Dirty Frag Chain, que son explotaciones de escrituras en caché deterministas, Bad Epoll es una condición de carrera que requiere un timing preciso, aunque con una tasa de éxito muy alta gracias al exploit de Chung.

Comandos para verificar la versión del kernel

Para confirmar si tu sistema está afectado, ejecuta:

uname -r

Si la versión comienza con 6.4, 6.5, 6.6, etc., el sistema es vulnerable a menos que tenga el parche aplicado.

Para verificar si el parche está instalado:

grep -r "a6dc643c6931" /usr/src/linux-headers-$(uname -r)/

Si no devuelve resultados, el parche no está aplicado.

Qué deberían hacer los administradores y equipos técnicos

Acciones inmediatas

1. Actualizar los kernels afectados:

     sudo apt update && sudo apt upgrade linux-image-generic
     

Verifica la versión instalada con:

     dpkg -l | grep linux-image
     

Busca versiones 6.4.0-XX-generic o superiores.

– RHEL/CentOS/Fedora:

     sudo dnf update kernel
     

Reinicia el sistema después de la actualización.

– Amazon Linux/EC2:

     sudo yum update kernel
     

Revisa el kernel actualizado con:

     uname -r
     

1. Verificar la aplicación del parche:

     git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
     cd linux
     git cherry-pick a6dc643c6931
     make -j$(nproc)
     sudo make modules_install && sudo make install
     sudo reboot
     

1. Priorizar sistemas críticos:

– Dispositivos Android: Aunque el exploit público aún no está disponible, aplica las actualizaciones de seguridad de Google lo antes posible. Para dispositivos Pixel, revisa:

     Settings > System > System update
     

– Entornos cloud: Actualiza las imágenes de los nodos en Kubernetes, EKS, AKS o GKE:

     # Ejemplo para EKS (AWS)
     aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup
     

Monitoreo y detección

1. Habilitar KASAN en kernels de prueba:

   echo 1 | sudo tee /proc/sys/kernel/kasan_stack_enable
   

Monitorea los registros del kernel con:

   dmesg | grep -i kasan
   

1. Auditar logs de exploits:

   journalctl -k | grep -i "epoll\|use-after-free"
   

1. Segmentar redes y contenedores:

– Usa políticas de seguridad en Kubernetes para restringir permisos de los pods:

     apiVersion: policy/v1
     kind: PodSecurityPolicy
     metadata:
       name: restricted
     spec:
       privileged: false
       allowPrivilegeEscalation: false
       requiredDropCapabilities:
         - ALL
     

Plan de respuesta para equipos de seguridad

1. Crear reglas de detección en SIEM:

     title: Bad Epoll Exploit Attempt
     id: 1001
     status: experimental
     description: Detecta intentos de explotación de CVE-2026-46242
     references:
       - https://thehackernews.com/2026/07/new-bad-epoll-linux-kernel-flaw-lets.html
     logsource:
       category: kernel
       product: linux
     detection:
       selection:
         message: "epoll: use-after-free detected"
       condition: selection
     falsepositives:
       - Pruebas de kernel
     level: critical
     

– Wazuh rules para monitorear cambios en el kernel:

     <rule id="100101" level="12">
       <if_sid>6001</if_sid>
       <match>kernel: epoll use-after-free</match>
       <description>Posible explotación de Bad Epoll (CVE-2026-46242)</description>
     </rule>
     

1. Simular ataques en entornos de prueba:

Conclusión

Para los equipos de DevOps e infraestructura, la prioridad es aplicar los parches disponibles lo antes posible, especialmente en sistemas críticos y entornos cloud. Para los equipos de seguridad, este fallo subraya la importancia de no confiar exclusivamente en herramientas automatizadas para la detección de vulnerabilidades, especialmente en problemas de sincronización complejos. Finalmente, la comunidad de código abierto debe tomar nota: incluso los modelos de IA más avanzados pueden pasar por alto fallos críticos, y la revisión humana sigue siendo indispensable.

Fuentes:

https://thehackernews.com/2026/07/new-bad-epoll-linux-kernel-flaw-lets.html

https://eng.uber.com/

https://www.oreilly.com/radar/