Qué se rompió, en términos sencillos

El 3 de julio de 2026, el investigador Jaeyoung Chung publicó Bad Epoll, registrado como CVE-2026-46242. Es una condición de carrera de uso después de liberar en el subsistema epoll del núcleo de Linux, la maquinaria estándar que usa un programa para vigilar muchos archivos y conexiones de red a la vez. Los servidores, los servicios de red y los navegadores web se apoyan todos en él, por lo que no se puede apagar sin más.

El efecto práctico es rotundo. Un atacante que ya tiene cualquier punto de apoyo con pocos privilegios en la máquina, un shell de una aplicación web comprometida, una aplicación móvil maliciosa, una cuenta de un contratista, puede escalar a root completo. La prueba de concepto de Chung, presentada al programa kernelCTF de Google, ensancha una ventana temporal que normalmente solo mide unas seis instrucciones de máquina y logra root aproximadamente el 99 por ciento de las veces. El núcleo 6.4 y posterior están afectados salvo que ya estén parcheados; las compilaciones más antiguas basadas en 6.1 no lo están.

Por qué solo local no significa poco riesgo

Resulta tentador archivar una escalada de privilegios local en el cajón de más tarde. Ese reflejo es erróneo para quien opera una flota. Las brechas modernas tienen dos pasos. El primer paso, una credencial expuesta, una sesión robada, un front-end web vulnerable, lleva a un atacante a la máquina como usuario limitado. Bad Epoll es el segundo paso que convierte a ese usuario limitado en root, desactiva el registro y transforma un incidente contenido en uno de todo el dominio.

El ángulo de Android agudiza el asunto. Una aplicación maliciosa o troyanizada que supera el bajo listón de instalarse ya puede aspirar a root en dispositivos con núcleo 6.4 o posterior. Para cualquier organización que permita al personal leer el correo corporativo en teléfonos personales, la frontera que suponía entre una aplicación mala y sus datos acaba de adelgazar. Esto es una historia de gestión de parches disfrazada de fallo del núcleo.

El punto ciego de la auditoría con IA que los operadores heredan

Aquí está el detalle que debería llegar al consejo de administración, no solo al equipo de seguridad. El mismo commit del núcleo de 2023 introdujo dos condiciones de carrera contiguas en unas 2.500 líneas de código epoll. El modelo Mythos de Anthropic detectó la primera, ahora registrada como CVE-2026-43074. Pasó por alto la segunda, la que se convirtió en Bad Epoll. Las condiciones de carrera son notoriamente difíciles de detectar, y la revisión automática, como la humana, no las detecta de forma uniforme.

La lección no es que la revisión de código con IA fallara. Es que un pase limpio de IA no es un certificado de despeje. Si sus responsables de ingeniería han empezado a citar auditorías automatizadas como prueba de que el código es seguro, este es el caso de estudio que dice: un resultado positivo estrecha el riesgo, no lo cierra. Trate la revisión con IA como una capa, financie el fuzzing y a especialistas humanos junto a ella, y no deje nunca que un informe verde de la máquina sea la razón para saltarse un control.

Qué hacer esta semana

Aplique la corrección original, el commit del núcleo a6dc643c6931, o el backport de su distribución, dando prioridad a los hosts expuestos a internet y multiinquilino donde es más probable que se ejecute código local no confiable. Para los parques de Android gestionados, distribuya las actualizaciones de seguridad del fabricante y confirme qué dispositivos van con núcleo 6.4 o posterior. Epoll no se puede desactivar, así que no hay atajo de configuración; el parche es la mitigación.

Luego use el momento como una prueba de gobernanza. Haga una pregunta en su próxima revisión de operaciones: si hoy se compromete una cuenta con pocos privilegios, qué impide que llegue a root para el viernes? Si la respuesta honesta depende de un parche que aún no ha programado, ha encontrado la brecha para la que se construyó este fallo.