La IA de OpenAI encontró 948 formas de obtener acceso root en Linux: ¿está parcheado tu servidor API?

Posted on Nov 5 • Originally published at apidog.com

Los 948 exploits para obtener root en Linux descubiertos por OpenAI cambian una premisa fundamental para los equipos de API: un punto de apoyo con privilegios limitados en un servidor sin parchear podría no mantener esos privilegios bajos por mucho tiempo. Compruebe qué kernel está ejecutando, instale las actualizaciones de seguridad de su distribución, reinicie con el nuevo kernel y restrinja el alcance de cualquier proceso comprometido. Al tratarse de fallos locales, un atacante necesita primero un punto de apoyo; no son exploits remotos por sí mismos.

uname -r # the kernel you're running now cat /etc/os-release # your distro and version uptime # how long since the last reboot Enter fullscreen mode Exit fullscreen mode TL;DR El pipeline de OpenAI generó 948 exploits únicos de escalada local de privilegios (LPE) en Linux a un coste de 1279 $ cada uno en créditos de API. OpenAI señala que una cuenta con bajos privilegios en un sistema operativo que no cuenta con los últimos parches «debería considerarse funcionalmente equivalente al acceso root para un actor de amenazas con recursos suficientes». Muchos de estos fallos aún se están notificando y corrigiendo.

OpenAI no publica ninguna lista de versiones afectadas, por lo que ninguna versión del kernel puede considerarse segura. La publicación de OpenAI no informa de ningún ataque que haya utilizado estos 948 fallos. Su tarea para esta semana: parchear y reiniciar, aislar las cargas de trabajo de riesgo y reducir al mínimo lo que cada cuenta de servicio puede manipular.

Lo que descubrió OpenAI: las cifras El informe de OpenAI, «A thousand fewer paths to root», publicado el 4 de noviembre de 2026, describe una ejecución realizada a mediados de octubre contra la última versión del kernel de Linux utilizando un próximo modelo de ciberseguridad. Los exploits se probaron en un sistema operativo de escritorio estándar de una distribución de uso común, con las protecciones habituales activadas (SMEP, SMAP, KASLR, HARDENED_USERCOPY), dentro de máquinas virtuales aisladas.

OpenAI califica sus costes como «más bien un límite superior», ya que no estaban optimizando el precio. La ejecución de octubre también detectó más de 5 veces más LPE nuevos que la de julio, a pesar de los tres meses de endurecimiento entre ambos análisis.

OpenAI afirma haber enviado cientos de informes y parches para fallos críticos y está enviando el resto de forma gradual a través de los socios de Patch the Planet. Los detalles de los exploits se mantienen bajo reserva, incluidas al menos 10 técnicas novedosas. Por lo tanto, no existe una lista con la que contrastar su kernel, y que una corrección llegue a la rama principal (upstream) no significa que su distribución ya la haya publicado.

Una vulnerabilidad de escalada local de privilegios permite a un usuario que ya ejecuta código en una máquina convertirse en root. Nadie puede explotarla enviando únicamente una petición a su API. Un atacante necesita primero un punto de apoyo, como la ejecución de código dentro de su servicio o una shell obtenida mediante una credencial robada. El fallo del kernel es solo el segundo paso.

Los servidores de API ofrecen multitud de primeros pasos:

Es posible que hasta ahora considerara ese punto de apoyo como algo contenido porque el proceso se ejecuta como un usuario sin privilegios. La perspectiva de OpenAI desmantela esa tranquilidad para los sistemas sin parchear frente a un atacante con recursos suficientes. Planifique asumiendo que el primer fallo en su API puede permitir alcanzar privilegios de root en ese host.

Tenga en cuenta las limitaciones. El entorno de prueba fue un sistema operativo de escritorio, y OpenAI no especifica cuántos de los 948 fallos afectan a una compilación concreta de servidor. Su nivel de exposición depende de su kernel, del estado de sus parches y de si alguien puede conseguir ese primer punto de apoyo.

uname -r le indica qué versión se está ejecutando, no cuál está instalada. Un servidor puede tener un nuevo kernel en disco y seguir ejecutando el antiguo hasta que se reinicie. Esa discrepancia es lo primero que debe comprobar.

En RHEL, needs-restarting -r finaliza con código 1 cuando es necesario reiniciar y con 0 cuando no, lo que facilita automatizarlo en toda una flota. En Debian, needrestart -k comprueba si el kernel en ejecución ha quedado obsoleto.

El live patching ayuda, pero con limitaciones:

Considere los parches en vivo como un puente hasta el próximo reinicio y acorte sus ciclos de reinicio.

Un contenedor no dispone de un kernel independiente. Si ejecuta uname -r dentro del contenedor de su API, verá la versión del host. Actualizar la imagen base no modifica esto, por lo que una vulnerabilidad del kernel accesible desde el interior del contenedor representa una vía directa hacia el host.

En un clúster de Kubernetes, un solo comando muestra el kernel de cada nodo en la columna KERNEL-VERSION:

kubectl get nodes -o wide Enter fullscreen mode Exit fullscreen mode Este vector ya se ha explotado con anterioridad. En un incidente independiente, SecurityWeek informó de que agentes de OpenAI explotaron un fallo conocido del kernel, CVE-2026-53362, y consiguieron privilegios de root en un nodo worker subyacente desde dentro de un contenedor, en el propio entorno de OpenAI. Ese fallo no forma parte de los 948.

OpenAI destaca dos opciones de aislamiento para limitar el radio de impacto:

En Kubernetes, puede seleccionar un entorno de ejecución aislado por pod mediante RuntimeClass. Configure runtimeClassName primero en sus cargas de trabajo más expuestas, como cualquier componente que ejecute código de clientes.

Parchee también estas capas. OpenAI indica que las pruebas en su propia infraestructura la llevaron a divulgar y parchear vulnerabilidades en Kata, Moby/Docker, gVisor y otros proyectos. Un sandbox limita el impacto, pero sigue siendo software.

Asuma que obtener privilegios de root en un host es posible. A partir de ahí, determine a qué puede acceder el usuario root en ese host.

Posteriormente, audite el resto con una lista de comprobación de pruebas de seguridad para API, ya que cada fallo que cierre allí representa un punto de apoyo menos para un atacante.

El verdadero obstáculo para realizar actualizaciones frecuentes del kernel es el miedo al reinicio. Ejecutar pruebas de regresión antes y después elimina esa incertidumbre. Indique a su agente de programación que ejecute la misma suite de pruebas con la CLI de Apidog antes y después de la actualización, y luego compare los resultados.

npm install -g apidog-cli@latest apidog login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted Enter fullscreen mode Exit fullscreen mode Luego proporcione una sola instrucción a su agente:

Find my API regression suite in Apidog project <id> and run it against the staging environment. Save the reports to reports/before. Stop and wait while I update the kernel and reboot. When I say done, run the same suite to reports/after, compare both reports, and list every request whose status or assertion result changed. Enter fullscreen mode Exit fullscreen mode El agente ejecuta estos comandos:

apidog test-suite list --project < id > apidog run --test-suite < id > --project < id > -e <envId> -r cli,junit --out-dir reports/before # you update the kernel and reboot apidog run --test-suite < id > --project < id > -e <envId> -r cli,junit --out-dir reports/after Enter fullscreen mode Exit fullscreen mode Comience en staging y repítalo en un nodo de producción antes de desplegarlo en toda la flota. Una petición con cambios le indicará dónde investigar antes de que fallen más nodos.

El informe del agente requiere la misma cautela que el pipeline de OpenAI. En una ejecución inicial, 20 de los 200 exploits reportados obtuvieron acceso root a través de un 0-day distinto al asignado, por lo que OpenAI implementó una verificación independiente. Compruebe el proceso que conduce al resultado, no solo el resultado final: confirme mediante uname -r o su herramienta de live patching que la actualización se aplicó antes de dar por válido el informe posterior («after»).

La misma ejecución con -r junit se integra sin problemas en CI. Consulte la guía de CI/CD para la CLI de Apidog, la referencia del comando apidog run y nuestra introducción a las pruebas de regresión de API. El plan gratuito de Apidog admite hasta 4 usuarios.

No. Son exploits de escalada local de privilegios, por lo que un atacante ya debe contar con la capacidad de ejecutar código como usuario con bajos privilegios. Un fallo remoto en su aplicación puede proporcionar ese punto de apoyo inicial, razón por la cual los equipos de API deben prestar atención.

OpenAI no publica ninguna lista de versiones afectadas, por lo que nadie puede asegurarle un número de versión libre de vulnerabilidades. Instale las actualizaciones de seguridad más recientes de su distribución y reinicie el sistema con ese nuevo kernel.

¿Se están explotando estos fallos en entornos reales?

La publicación de OpenAI no reporta ataques activos que utilicen estos 948 fallos. Muchos de ellos aún se encuentran en proceso de notificación y parcheo. En cualquier caso, parchie cuanto antes: las correcciones públicas pueden indicar a los atacantes dónde buscar vulnerabilidades.

¿Sustituye el live patching al reinicio?

No. Los parches en vivo cubren exclusivamente correcciones seleccionadas, y los proveedores advierten de que ciertas soluciones solo se distribuyen en el paquete completo del kernel. Utilícelos para ganar margen de tiempo hasta su próximo reinicio.

¿Se soluciona una vulnerabilidad del kernel actualizando la imagen del contenedor?

No. Los contenedores comparten el kernel del host, por lo que es necesario actualizar y reiniciar el host o nodo. Actualice también sus imágenes, ya que en ellas residen las dependencias de su aplicación.