Cloudflare corrige falla de aislamiento en GLM-5.3

Según el análisis de Cloudflare, el problema combinó una configuración de memoria menor que la ventana de contexto del modelo y una falla en el manejo de pedidos rechazados por SGLang. La empresa dice que corrigió el servicio en septiembre y no encontró otros modelos afectados.

En este artículo vas a ver:

• Lo que Cloudflare confirmó sobre GLM-5.3
• Cómo el pool de KV cache quedó menor que el contexto
• Por qué SGLang continuó un pedido rechazado
• Qué verificaciones ayudan a reducir fallas entre clientes

Lo que Cloudflare confirmó sobre GLM-5.3 en Workers AI

La exposición involucró únicamente al modelo @cf/zai-org/glm-5.3 en Workers AI, según Cloudflare. El período informado va desde el lanzamiento, el 27 de agosto de 2026, hasta la retirada y corrección del servicio, el 9 de septiembre.

Cloudflare contabilizó 155 respuestas afectadas, todas asociadas a prompts por encima de 681.280 tokens. La empresa afirma que, tras excluir sus propias pruebas y las del investigador, el volumen y el horario eran compatibles con un uso normal de contexto largo, sin evidencia de explotación deliberada y repetida.

El relato no atribuye intención maliciosa al modelo. La empresa describe una falla de configuración junto con un error de ejecución en SGLang, el motor de inferencia que atendía al modelo en modo distribuido.

La información importante para quien integra un endpoint de modelo es el tipo de exposición: una respuesta podía incluir contenido de pedidos anteriores de otros clientes. El informe no identifica públicamente cada contenido involucrado, por lo que no cabe presumir que todas las respuestas contenían credenciales o datos personales.

Cómo la ventana de GLM-5.3 superó el tamaño del KV cache

GLM-5.3 se configuró con una ventana de contexto de 1.048.576 tokens. Sin embargo, el pool de KV cache en las GPUs de prefill tenía capacidad para 681.280 tokens. La ventana anunciada, por tanto, permitía prompts más grandes que la memoria disponible para procesarlos en esa etapa.

KV cache es una memoria temporal que guarda estados intermedios del modelo mientras procesa el prompt y genera una respuesta. SGLang organiza esa memoria en páginas reutilizables para atender varias solicitudes sin asignar toda la memoria desde cero en cada pedido.

En el modo usado por Cloudflare, el trabajo se dividía entre dos grupos de GPUs. El prefill procesaba el prompt y preparaba el KV cache. El decode recibía ese cache y generaba la respuesta token por token.

El diagrama de Cloudflare muestra el flujo saludable y el flujo rechazado. En la falla, el decode reservaba ocho páginas, pero el prefill escribía solo la primera. Las otras siete seguían guardando contenido de solicitudes anteriores.

Por qué SGLang continuó una solicitud que debería haberse rechazado

Cuando el prompt excedía el pool, SGLang debería devolver un error al cliente. En cambio, la rutina de rechazo cambiaba el prompt por un marcador de un token y guardaba el error en to_finish, sin completar finished_reason.

Las colas de admisión de prefill y decode verificaban req.finished(). Como el rechazo quedaba en un campo distinto, la función seguía tratando la solicitud como activa y la dejaba avanzar. El prefill procesaba el marcador, escribía una página y señalaba que la transferencia había terminado.

El decode recibía la señal y leía las ocho páginas reservadas. Como solo una había sido sobrescrita por la solicitud actual, las demás podían contener tokens de solicitudes anteriores. La respuesta aún podía llegar con HTTP 200, a pesar de incluir estado antiguo del KV cache.

Este detalle muestra por qué no basta con probar solo el código HTTP. Cloudflare reconoció que las pruebas anteriores verificaban la respuesta y el rendimiento en contextos largos, pero no comprobaban la coherencia del contenido generado.

Cómo Cloudflare corrigió GLM-5.3 y SGLang

Cloudflare retiró el modelo el 9 de septiembre, ajustó la configuración y restauró el servicio el mismo día. El nuevo pool de prefill pasó a soportar cerca de 2,04 millones de tokens, aproximadamente el doble de la ventana de contexto configurada.

La empresa también aplicó correcciones a la ruta de rechazo de SGLang. El motor pasó a terminar la solicitud rechazada antes de asignar memoria o transferir KV cache. El informe recomienda que los operadores de SGLang usen la versión 0.5.22 o posterior.

Además de la corrección, Cloudflare dice que empezó a medir el pool real de KV cache contra el tamaño de contexto en cada nodo. La verificación debe repetirse después de cambios en pesos, cuantización, paralelismo o uso de memoria de GPU.

La empresa afirma que GLM-5.3 fue el único modelo afectado. También reporta haber aplicado la corrección del motor y las nuevas verificaciones a las demás implementaciones de SGLang que opera.

Qué enseña el incidente a quien opera agentes y modelos

Quien hospeda modelos necesita probar límites reales de memoria, además de los límites declarados en la configuración. Una prueba segura debe incluir prompts por encima de la capacidad, cuentas separadas, marcadores distintos en cada sesión y validación del contenido recibido, no solo del estado HTTP.

Quien usa APIs de modelos debe preguntar cómo el proveedor aísla el estado entre solicitudes, qué errores aparecen cuando un contexto no cabe y cómo la empresa gestiona incidentes. El caso también refuerza la importancia de limitar herramientas y datos accesibles a cada agente.

Para comparar riesgos de agentes hospedados y locales, vea la guía sobre agentes de IA para programar gratuito. El análisis de Cohere sobre una prueba con Qwen3.8 también muestra por qué sandbox, revisión y límites de herramientas deben formar parte de la evaluación.