Cloudflare confirma una exposición entre clientes en Workers AI con GLM-5.3

Un fallo de aislamiento, no una intrusión confirmada

Cloudflare ha explicado cómo un error en Workers AI hizo que algunas respuestas del modelo GLM-5.3 incluyeran fragmentos de solicitudes de otros clientes. El incidente duró del 27 de agosto al 9 de septiembre, pero se conoció públicamente el 26 de octubre: la compañía contó 155 respuestas afectadas, todas generadas a partir de prompts de más de 681.280 tokens. Es una cifra de respuestas, no un recuento publicado de personas u organizaciones.

El alcance declarado es estrecho: Cloudflare atribuye el problema a GLM-5.3 y dice que no encontró otros modelos de Workers AI afectados. Tras descontar sus propias pruebas y las del investigador que reportó el fallo, la empresa no halló indicios de explotación deliberada; el patrón observado encajaba con uso normal de contexto largo. Eso limita lo que puede afirmarse: hubo exposición entre clientes, pero el informe no demuestra que un atacante la buscara ni que se extrajera un conjunto de datos a escala.

-SecureCrew dice: que una respuesta salga con HTTP 200 no certifica que haya contestado a la persona correcta; a veces solo certifica que el bug también sabe ser educado.-

La frontera rota estaba en la caché

Workers AI ejecutaba ese modelo con SGLang, un motor de inferencia de código abierto. En este despliegue, el procesamiento se repartía entre servidores de prefill y decode: una etapa procesa el prompt y prepara los datos para otra que genera la respuesta. El modelo aceptaba contextos de hasta 1.048.576 tokens, pero la caché KV disponible en los servidores de prefill solo podía alojar 681.280.

La caché KV conserva representaciones intermedias de los tokens para no recalcular el contexto a cada paso. Sus páginas de memoria se reutilizan entre solicitudes; por eso el motor debe garantizar que decode lea únicamente las páginas escritas para esa petición. La diferencia entre la ventana anunciada y el espacio real volvió alcanzable un camino de rechazo que las pruebas de Cloudflare no habían validado con suficiente cuidado.

Cuando llegaba una solicitud demasiado larga, SGLang la marcaba para rechazarla y la sustituía internamente por un prompt de un token. En el modo distribuido, sin embargo, las colas trataban esa solicitud como si siguiera activa: prefill procesaba el marcador mínimo, transfería una página y señalaba que el traspaso había terminado. Decode había reservado espacio para el prompt completo y leyó páginas que la solicitud nueva no había sobrescrito; todavía podían contener datos de peticiones anteriores.

-SecureCrew dice: la memoria compartida no necesita un atacante ingenioso para filtrar datos; a veces basta con que dos componentes discrepen sobre quién es dueño de una página.-

El efecto observado fue que respuestas de GLM-5.3 podían contener texto de sesiones de otros clientes del mismo modelo. Cloudflare no publicó un número de cuentas afectadas ni una lista de campos expuestos, así que no conviene convertir las 155 respuestas en 155 víctimas. Tampoco debe extenderse el caso a todos los modelos generativos o a cualquier instalación de SGLang: la condición dependía de la ruta distribuida y de esa configuración concreta.

La corrección cubre configuración y motor

Cloudflare retiró GLM-5.3 el 9 de septiembre mientras investigaba, ajustó el tamaño del pool de prefill y desplegó una corrección en el motor antes de restaurar el modelo esa misma tarde. La corrección combinó capacidad y código: la nueva configuración dejó espacio para la ventana completa y el cambio de motor hace que una solicitud rechazada termine antes de entrar en el traspaso. La compañía afirma que reprodujo el fallo con el investigador y validó las correcciones antes de reabrir el servicio.

El equipo de SGLang publicó también la secuencia de arreglos incorporados al proyecto. La primera corrección de admisión llegó en la serie 0.5.20 y tuvo cambios posteriores en 0.5.21 y 0.5.22; Cloudflare recomienda 0.5.22 o posterior a quienes operen SGLang en prefill/decode distribuido. Además, el tamaño real de la caché debe compararse con el contexto configurado en cada nodo después de cambios de modelo, memoria o paralelismo: una cifra de contexto por sí sola no prueba que el camino que procesa ese contexto sea seguro.

-SecureCrew dice: los límites de configuración sirven cuando las dos mitades del sistema los entienden igual; si no, el límite es más bien una sugerencia con buena reputación.-

Para operadores, la pregunta útil no es si usan inteligencia artificial en abstracto, sino si ejecutan SGLang con transferencia de KV entre etapas y qué versiones incorporan los arreglos. El informe de Cloudflare describe el incidente de su servicio; el de SGLang detalla el mecanismo y las protecciones del motor. Son piezas complementarias, no una señal de que todos los despliegues hayan sufrido la misma exposición.

Diccionario de la Crew

Caché KV — memoria que guarda claves y valores intermedios de atención para reutilizar el contexto ya procesado durante la generación.

Prefill y decode — etapas separadas de inferencia: una procesa el prompt y prepara la caché; la otra consume esa caché para generar tokens.

SGLang — motor de código abierto para servir modelos de lenguaje, incluido el modo distribuido descrito en el incidente.