Mil doscientos treinta y ocho hallazgos candidatos. De esos, mil setecientos veinticuatro vulnerabilidades que se pudieron reproducir en entorno aislado. Y de esas, 948 exploits de escalada local de privilegios que funcionan de verdad contra una distribución de Linux con escritorio stock y nada debilitado. Costo de la corrida, a mediados de octubre: 1.213.430 dólares en API. Menos de 1.279 dólares por cada camino a root. Lo reportó OpenAI el 4 de noviembre y lo tuve que leer dos veces, porque los números no entraban.
Lo que hizo la máquina
El pipeline tiene cinco etapas: unos agentes eligen qué partes del kernel valen la pena auditar, otros barren esas zonas buscando hallazgos, después viene validación dinámica del hallazgo, evaluación de explotabilidad y generación de parches. Al final revisa un humano antes de reportar a los mantainers. El paquete que sale incluye causa raíz, un proof-of-concept mínimo que crashea, el exploit completo y el parche candidato listo para discusión upstream.
En la variante kernelCTF —kernel con superficie de ataque reducida— el mismo pipeline sacó 21 exploits de LPE considerados 0-day, gastando unos 32.936 dólares. Para dimensionar: kernelCTF había aceptado 26 exploits 0-day de LPE en todo 2026, aportados por humanos. De paso, los agentes encontraron además un bug de QEMU TCG en la propia infraestructura de testeo, sin acceso al código fuente de QEMU.
Los números incómodos
Si aplicas los bounties históricos de competencias tipo Pwn2Own —20.000 dólares por un LPE de kernel—, esos 948 exploits valdrían entre 18,9 y 66,3 millones de dólares: entre 16 y 55 veces el costo de la corrida. Para un programa de bug bounty es un chilazo. Pero lo que más me incomoda no es la cantidad, es la pendiente: el modelo de octubre encontró más de 5 veces más LPEs novedosos que el run de julio con el modelo anterior, pese a tres meses de endurecimiento de la plataforma entre medio. La defensa no está ganando esta carrera.
Lo que significa para tu servidor
Para quien administra VPS esto cambia el modelo mental. La conclusión dura del reporte: una cuenta sin privilegios en un kernel sin parchear equivale, en la práctica, a root para un atacante con recursos. Todo lo que uno hace a diario —separar servicios, usuarios dedicados, permisos ajustados— sirve para contener el daño una vez que están adentro, no para impedir la escalada. Y la idea reconfortante de que «es solo un contenedor» queda en entredicho: si comparten el kernel del host y el kernel está remendado a media, la frontera es ficticia.
La recomendación técnica es defensa en profundidad con aislamiento de verdad: Firecracker, gVisor, sandboxes con hipervisor propio. Después de leer el reporte le puse ojo a mover las tareas más expuestas de mi flota desde contenedores compartidos hacia aislamiento más fuerte; no me parece frontera suficiente lo que tenía. Y sí, esa semana hay unattended-upgrades y reinicio con kernel nuevo: el parche que está en el repositorio no existe hasta que instalas y reinicias.
Mi opinión
El hallazgo nunca fue el cuello de botella; el triage sí. Miles de candidatos que nadie puede revisar a mano era exactamente el problema, y una máquina que además escribe el parche candidato cambia la economía completa del bug hunting. El bottleneck migra del descubrimiento a la adopción del parche. Durante los diez días que duró el escaneo, la comunidad de Linux parcheó más de 100 LPEs y otros 300 estaban en discusión pública. Habla muy bien del ecosistema y muy mal de nuestras ventanas de exposición.
Y ojo, que nadie sea ingenuo: esto no se queda del lado defensivo. El mismo pipeline corriendo sin revisión humana y reportando a un mercado gris en vez de a los mantainers es la pesadilla obvia que viene. Mientras tanto, la ventaja la tiene quien parchea rápido. Aprovecha de subir el kernel de tus servidores esta semana; después de esto, la pregunta ya no es si alguien puede escalar, sino si tu parche llegó antes que su exploit.
Fuente de inspiración: A thousand fewer paths to root
