IA

SGLang: un RCE en el motor de inferencia que entró en el TEE de NEAR AI

Un atacante explotó un fallo de ejecución remota en SGLang, el motor de inferencia de NEAR AI, y llegó hasta dentro de su entorno de ejecución confiable.

Fernando Luis

— 11 min read

El domingo 8 de noviembre, un atacante encontró un fallo de ejecución remota de código en SGLang, el motor de inferencia de código abierto que servía los modelos de NEAR AI, y lo explotó en uno de sus servidores de inferencia. Desde ahí se movió hacia dentro: alcanzó un sistema interno detrás de una función ya retirada, se llevó los datos de cuenta de unos 100 usuarios y tocó 18 agentes de IA cuyo historial de conversaciones, ajustes y registros quedaron expuestos.

Lo más incómodo del caso no es el fallo en sí. Es lo que la respuesta de la compañía revela sobre cómo se protege la inferencia confidencial, y por qué un entorno de ejecución confiable protege del operador y del anfitrión, pero no protege de una vulnerabilidad en el programa que se ejecuta dentro.

NEAR AI publicó su informe de incidente el 9 de noviembre. Es un informe honesto: no identifica el fallo con un número CVE, no dice qué versiones de SGLang están afectadas y ni siquiera confirma si el proyecto ya publicó una corrección. Lo que sí documenta, con detalle, es el camino que siguió el atacante y qué datos se llevaron. The Hacker News recogió la historia el 10 de noviembre con los mismos datos.

Qué es SGLang y por qué está en el centro de todo

SGLang es, según su propia descripción en GitHub, un «framework de servicio de alto rendimiento para modelos de lenguaje grandes y multimodales». Es decir: no es un modelo, es la capa que carga los pesos, reparte las peticiones entre las GPU y devuelve tokens. Cuando pides una respuesta a un modelo autoalojado, en algún punto de la cadena hay un SGLang (o algo parecido) orejándolo.

El proyecto es popular: 38.693 estrellas y 10.339 forks en GitHub en el momento de escribir esto, con miles de commits al mes. La versión v0.5.23, publicada el 2 de noviembre, reunió 1.007 pull requests de 257 personas. Es infraestructura de producción real y, como toda infraestructura de producción real, queda expuesta a internet en cuanto alguien la despliega.

El punto clave del incidente es que SGLang no es un componente cualquiera de la pila de IA. Es la pieza que ve las peticiones completas del usuario, las lleva a un modelo y devuelve las respuestas. Un fallo de ejecución remota de código ahí no se limita a robar un archivo de configuración: controlas el proceso que sostiene el modelo.

Lo que pasó, en orden

Según el informe, el atacante explotó un fallo de ejecución remota de código en SGLang. Eso le dio ejecución de código en un servidor de inferencia. Desde ese servidor alcanzó la infraestructura interna de NEAR AI.

Lo que hizo después, en orden cronológico:

  • Alcanzó un sistema interno detrás de Private Chat, un producto que la propia compañía ya había retirado. De ahí descargó los datos de cuenta de alrededor de 100 usuarios: direcciones de correo electrónico, nombres y, en algunas cuentas, información de plan y saldo.
  • Alcanzó 18 agentes de IA en un despliegue antiguo de NEAR AI Agents. De esos agentes se llevó datos que incluían el historial de chat, los ajustes y los registros.
  • En los registros de esos agentes aparecieron las claves de API de dos clientes de NEAR AI Cloud. La compañía las revocó.
  • El 8 de noviembre el atacante pudo observar las peticiones que se procesaban en el servidor comprometido, incluidas las que se estaban ejecutando en modo confidencial.

Un dato importante del informe: no hay indicio de que se accediera a las conversaciones almacenadas de Private Chat ni a los archivos subidos. Los usuarios afectados son los que aparecen en los registros de cuentas, no los que estaban chateando.

Y hay una advertencia explícita para los usuarios de NEAR AI que no han sido contactados: la compañía pide que se traten con cautela los mensajes no solicitados que mencionen la cuenta o el saldo. Los contactos legítimos salen de [email protected].

El punto ciego: el modo confidencial no salvó a nadie

Aquí está la parte que merece un artículo entero por sí sola.

NEAR AI opera un servicio de inferencia confidencial: los prompts se procesan dentro de un entorno de ejecución confiable, un TEE respaldado por hardware, con el propósito de que ni el operador ni el anfitrión puedan leer lo que el usuario escribe. Es el mismo tipo de arquitectura que Brave describió en octubre para su asistente Leo: el navegador cifra cada consulta con Oblivious HTTP, el TEE presenta una atestación firmada por hardware que verifica qué código corre dentro, y solo entonces se entrega la clave de descifrado.

La lección del incidente expone el límite exacto de esa promesa, y NEAR AI la enuncia sin rodeos en su propio informe: el cómputo confidencial protege los datos frente al operador y el anfitrión. No protege frente a una vulnerabilidad en el software que se ejecuta dentro del entorno.

Y SGLang se ejecutaba dentro del TEE. Eso significa que el atacante no necesitó romper el hardware, ni extraer las claves, ni escapar del entorno: le bastó explotar el programa que ya estaba dentro. El TEE le garantizó que nadie más que el proceso legítimo leería el prompt, y ese proceso legítimo resultó ser el que tenía el fallo.

Es un recordatorio incómodo para quien vende «privacidad verificable»: la atestación de hardware demuestra qué código se está ejecutando, no que ese código esté libre de errores. Un software con un RCE y una atestación válida sigue siendo un software con un RCE. La atestación sube la evidencia de integridad; no sube la calidad del código.

Brave, en su blog técnico, llegó a una conclusión similar con otras palabras al hablar de los pesos abiertos: la apertura no es suficiente, hay que verificar lo que realmente se ejecuta. Lo que aquí se rompe es el paso intermedio, ese que da por hecho que el software dentro del enclave es correcto.

Los 18 agentes: la sombra de un despliegue antiguo

Hay otro detalle en el recuento que merece atención, porque es la clase de error que se repite en cualquier infraestructura con años de historia.

Los 18 agentes afectados estaban en un despliegue antiguo de NEAR AI Agents que no se ejecutaba dentro del entorno de ejecución confiable. Es decir: la compañía tenía dos poblaciones de agentes, una dentro del perímetro protegido y otra fuera, heredada de antes de la migración.

El atacante no tocó los agentes protegidos, al menos según el informe. Llegó a los que estaban fuera. Es un recordatorio de que el perímetro de seguridad se define por la cobertura real, no por la cobertura teórica: cuando una parte del sistema migra a un modelo nuevo (enclave, segmentación, autenticación fuerte) y otra se queda atrás, el atacante elige la parte que se quedó atrás, porque es la más barata de entrar.

La compañía afirma que Private Chat y el despliegue antiguo ya no estaban en servicio activo de cara al usuario. Que un sistema «obsoleto» siga siendo un sistema alcanzable y con datos dentro no es una contradicción: es la norma.

Un patrón, no un incidente aislado

Hay que ser cuidadoso con una cosa: NEAR AI no ha identificado qué fallo se explotó. No hay CVE, ni versiones afectadas, ni confirmación de que exista un parche publicado por el proyecto. Cualquiera que diga cuál era el fallo concreto está especulando.

Lo que sí se puede mirar es el historial de vulnerabilidades publicadas de SGLang en la base de datos OSV, que a día de hoy recoge 20 avisos para el paquete de PyPI. Y el patrón es muy repetitivo: ejecución remota de código sin autenticación.

  • CVE-2026-7304: ejecución remota de código sin autenticación a través de la opción --enable-custom-logit-processor. Vector de red, complejidad baja, sin privilegios y sin interacción de usuario, con impacto alto en confidencialidad, integridad y disponibilidad.
  • CVE-2026-7301: el planificador multimodal deserializa datos pickle no confiables en el socket ROUTER que escucha en 0.0.0.0.
  • CVE-2026-3059: ejecución remota de código sin autenticación en el módulo de generación multimodal a través del broker ZMQ.
  • CVE-2026-3060: ejecución remota de código sin autenticación en el módulo de desagregación de codificador paralelo.
  • CVE-2026-7302: recorrido de rutas sin autenticación en el runtime de generación multimodal.
  • CVE-2025-10164: ejecución remota de código por deserialización insegura en update_weights_from_tensor.
  • CVE-2026-3989: un pickle.load() sin validar en replay_request_dump.py.

Seis avisos de ejecución remota de código sin autenticación en menos de un año, con CVSS máximo en varios casos. El patrón técnico es siempre el mismo: el servidor de inferencia acepta peticiones que vienen de la red y las convierte en acción sobre el sistema (carga de pesos, deserialización, ejecución de un procesador personalizado). Cada una de esas fronteras es una frontera de confianza mal puesta.

No repito que cualquiera de estos sea el fallo del incidente. Repito que un proyecto con este historial de avisos públicos es un objetivo razonable para alguien que busca un servidor de inferencia expuesto, y que la ausencia de un CVE oficial no reduce en nada el riesgo para quien opera uno.

Dos problemas de autorización que siguen abiertos en el repositorio

Además del historial de CVEs, hay dos incidencias abiertas en el propio repositorio de SGLang que ilustran el mismo problema de fondo: el servidor de inferencia está diseñado para ser fácil de exponer, y su modelo de autenticación tiene costuras.

El endpoint de volcado con eval(). El issue #44188, abierto el 14 de octubre, describe una ejecución remota de código en el proceso del planificador. Cuando el servidor arranca con DUMPER_SERVER_PORT=reuse, la ruta /dumper/{method} se registra en la API principal del modelo con nivel de autorización ADMIN_OPTIONAL, y /dumper/configure pasa el cuerpo JSON directamente a la configuración, incluido el campo de texto filter. Durante la ejecución, ese filtro se evalúa con eval() de Python en python/sglang/srt/debug_utils/dumper.py. Aunque se quitan los __builtins__, los auxiliares expuestos (re.search y re.match) son objetos función que conservan su atributo __globals__, que lleva de vuelta a los globales del módulo y a los builtins reales: con eso se recupera __import__ y se ejecuta Python arbitrario. La corrección propuesta en el PR #45998 sustituye eval() por un evaluador AST restringido, y a fecha de este artículo sigue sin fusionarse.

La frontera usuario/administrador que se colapsa. El issue #43706 describe un caso de configuración muy habitual: cuando solo se configura --api-key y --admin-api-key está ausente, quien tiene la clave de API corriente queda autorizado también en los endpoints marcados ADMIN_OPTIONAL. El fragmento de código correspondiente está en python/sglang/srt/utils/auth.py, en el bloque que decide la autorización para ese nivel. El efecto es que una separación de privilegios que parecía existir en el diseño no existe en el despliegue real más habitual.

Y la ausencia de controles en la capa de petición. El PR #43610 lo admite sin rodeos en su propia motivación: el servidor HTTP tiene autenticación (--api-key) pero nada más en la capa de petición, sin limitación de tasa, sin controles de IP y sin cribado de carga útil. El middleware de seguridad que propone es opcional y está desactivado por defecto.

Puestas juntas, estas tres piezas describen un servidor de inferencia que asume que la red de delante es de fiar, que la clave de API que se comparte con los clientes es distinta de la de administración, y que quien despliega va a poner un proxy que filtre lo que haga falta. En un entorno de producción maduro, con un TEE alrededor y una promesa de inferencia confidencial por delante, esas tres suposiciones son justo las que hay que revisar.

Lo que hizo NEAR AI, y lo que sigue sin saberse

La respuesta fue rápida y, en lo que importa, amplia: al detectar el ataque revocaron todas las sesiones activas y las credenciales de administración, reemplazaron todos los tokens de los agentes, retiraron Private Chat, desplegaron el arreglo del fallo de SGLang en todos sus servidores de inferencia, rotaron el resto de credenciales y completaron una revisión forense completa. El acceso a NEAR AI Cloud quedó restaurado. Además, declaran que hacen las notificaciones regulatorias que correspondan y han avisado individualmente a los propietarios de los 18 agentes.

La decisión de fondo que más me gusta: van a tratar el software de inferencia con el mismo rigor que el propio enclave. El razonamiento es correcto y es la lección que debería quedarse: si tu modelo de seguridad depende de que el software dentro del hardware sea correcto, ese software es parte de tu perímetro crítico y tiene que auditarse, probarse y recibir respuesta a vulnerabilidades como el hardware que lo rodea. Además mantienen públicos el código, las dependencias y las configuraciones de despliegue de su pila de inferencia confidencial, para que cualquiera pueda verificar qué es lo que realmente corre.

Lo que no sabemos: cuál era el fallo, qué versiones de SGLang estaban afectadas, si el proyecto publicó una corrección y si hay algún CVE en camino. También hay un cabo suelto con significado para el usuario final: Brave cuenta en su blog técnico que su asistente Leo ejecuta el modelo abierto GLM 5.3 Flash dentro de un TEE operado por NEAR AI, con cifrado de extremo a extremo y atestación de hardware. NEAR AI no ha dicho si el servidor afectado llegó a procesar alguna de esas conversaciones. La respuesta honesta es que no lo sabemos, y que ese «no lo sabemos» es exactamente el tipo de incertidumbre que un producto de privacidad verificable debería poder resolver con evidencia.

Qué hacer si operas un servidor de inferencia

Si tienes SGLang (o cualquier motor de inferencia) expuesto, la lección de este incidente se traduce en una lista corta:

  • Trata el motor de inferencia como el activo crítico, no como una herramienta. Es donde viven los prompts, las claves y las respuestas. Un RCE ahí no es un incidente de aplicación, es un incidente de plataforma.
  • No expongas el puerto de gestión a internet sin una capa de control. Autenticación robusta, limitación de tasa, lista de IP permitidas y filtrado de carga útil delante del servidor. El PR #43610 propone exactamente eso y está desactivado por defecto: no esperes al proyecto para activarlo tú.
  • Separa las claves de verdad. Configura --admin-api-key aunque creas que no hace falta. Con una sola clave, la separación entre usuario y administrador es nominal.
  • Audita el despliegue, no solo el código. El despliegue antiguo de agentes fue el que se rompió. Inventariar qué instancias están en producción, dentro de qué perímetro y con qué datos es parte del trabajo.
  • Revisa el historial de avisos antes de actualizar. Seis avisos de ejecución remota de código sin autenticación en un año son un argumento a favor de una versión parcheada y de un inventario real de lo que tienes desplegado.

Y para quien usa servicios de inferencia confidencial como usuario final: la lección no es que dejemos de confiar en los TEE, sino que entendamos qué protegen exactamente. El hardware te garantiza que nadie externo lee tu prompt. No te garantiza que el programa que lo procesa no tenga un fallo, y no te garantiza que las claves de tus conversaciones no se queden escritas en un registro que alguien más puede leer. De hecho, en este incidente, dos claves de API aparecieron precisamente en esos registros.

La lección de fondo

La infraestructura de IA heredó un hábito de la web: confiar en la red de delante. Un servidor de inferencia se despliega, se le pone una clave, se le da un nombre de dominio y a servir. Pero un motor de inferencia es, por diseño, un programa que recibe peticiones de cualquiera y las ejecuta sobre un sistema con pesos, claves y memoria. Cada punto donde el sistema traduce una petición en acción es una frontera de confianza, y un proyecto con 38.000 estrellas y mil pull requests por ciclo tiene muchas.

El incidente de NEAR AI no se resuelve con un parche. Se resuelve con una idea que ya estaba en su propio informe, y que conviene repetir aquí: el software que corre dentro de tu perímetro de confianza es parte de tu perímetro de confianza. El TEE protege el enclave de los demás. No protege el enclave de los errores de su propio motor de inferencia.

Y si algo bueno sale de esta historia, es que el informe de NEAR AI es un modelo de cómo se comunica un incidente de IA: qué se verificó, qué no, qué se sabe y qué no, sin disfrazar la incertidumbre de certeza.

Fuentes

Read more