Cloudflare afirma que un error en GLM-5.3 filtró 155 respuestas entre sesiones de distintos clientes

El 26 de octubre de 2026, Cloudflare publicó un informe sobre el incidente en el que reveló una exposición de la caché KV entre solicitudes en el modelo GLM-5.3 de su plataforma Workers AI. A raíz de ella, 155 respuestas a instrucciones muy largas incluyeron datos de las sesiones de otros clientes.

El investigador de seguridad Gadi Evron, de Knostic, informó a Cloudflare del problema de aislamiento entre clientes el 8 de septiembre de 2026, a través del programa HackerOne de la empresa. La exposición afectó al modelo, disponible como @cf/zai-org/glm-5.3, desde el 27 de agosto de 2026, fecha en que GLM 5.3 se lanzó en Workers AI. Cloudflare corrigió el problema y restableció el modelo el 9 de septiembre de 2026. También afirmó que confirmó que ningún otro modelo alojado en Workers AI se había visto afectado.

Las 155 respuestas afectadas correspondían a instrucciones de más de 681,280 tokens. Cloudflare afirmó que, tras excluir sus propias pruebas y las solicitudes del investigador, las solicitudes que identificó coincidían en el momento y el volumen con un uso habitual de contextos largos, en lugar de responder a una explotación reiterada del error, y que no encontró indicios de explotación deliberada.

Los dos problemas que provocaron la exposición

GLM es un modelo de generación de texto de Z.ai diseñado para flujos de trabajo de programación con agentes; es uno de los muchos modelos disponibles a través de Workers AI. Cloudflare ejecuta GLM 5.3 con SGLang, un motor de inferencia de código abierto, en una configuración desagregada: las GPU de prellenado procesan la instrucción y generan su caché KV; después, transfieren esa caché mediante acceso remoto directo a memoria (RDMA), a través de Mooncake, a las GPU de decodificación, que generan la respuesta. La caché KV es un conjunto compartido de páginas de tamaño fijo. Las páginas no se ponen a cero entre solicitudes, por lo que el motor debe llevar el control de quién es propietario de cada página.

El informe atribuye la exposición a dos problemas. El primero fue un error de configuración: Cloudflare desplegó GLM 5.3 con una ventana de contexto de 1,048,576 tokens, pero el conjunto de caché KV de sus GPU de prellenado solo tenía capacidad para 681,280 tokens. Cloudflare afirmó que conocía la discrepancia antes del lanzamiento, pero esperaba que el motor devolviera un error ante cualquier instrucción que no pudiera procesar. Como sus pruebas con contextos largos devolvían respuestas satisfactorias, no consideró que la discrepancia fuera un problema. La empresa señaló que sus pruebas validaban los códigos de respuesta HTTP y el rendimiento del motor con contextos largos, pero no la salida ni la coherencia del modelo. Ahora comprueba directamente el tamaño del conjunto KV frente a la longitud del contexto antes de implementar cualquier cambio en una configuración desagregada.

El segundo problema fue un error de SGLang al gestionar solicitudes que excedían la longitud permitida en el modo desagregado de prellenado y decodificación. Si una instrucción no cabía en el conjunto, el sistema la marcaba internamente como rechazada y la sustituía por un marcador de posición de un token, pero el prellenado seguía generando una caché KV para ese marcador y señalaba que la transferencia había finalizado. A continuación, el nodo de decodificación generaba una respuesta prestando atención a páginas de caché obsoletas que aún contenían datos de solicitudes anteriores, y el cliente recibía una respuesta HTTP 200 en vez de HTTP 400.

El equipo de SGLang señala en su propia publicación coordinada que la ruta de rechazo en un solo nodo devolvía un error. Por tanto, el problema solo se producía al servir solicitudes en modo desagregado. Otro usuario había notificado el error a SGLang como el problema n.º 30233 el 6 de julio de 2026; Cloudflare afirmó que lo detectó durante su investigación.

Respuesta al incidente y medidas correctivas

Cloudflare empezó a verificar el informe a las 08:00 UTC del 9 de septiembre de 2026 y declaró un incidente de seguridad a las 13:22, después de que su equipo de Seguridad de Producto reprodujera la filtración con dos cuentas independientes en 25 minutos. A las 14:00, configuró GLM 5.3 como privado; a las 14:35, identificó la causa raíz; a las 14:52, había actualizado todos los nodos de prellenado con la configuración corregida; a las 19:04, había reconstruido todo el despliegue con un parche del motor desarrollado por Cloudflare; y a las 19:40, restableció el acceso público al modelo. La página de estado de Cloudflare registró que el incidente de Workers AI comenzó a las 10:25 a. m. EDT del 9 de septiembre de 2026, se identificó a las 11:02 a. m. EDT y se resolvió a las 4:09 p. m. EDT.

La corrección de la configuración siguió el modelo de GLM 5.2 y liberó suficiente memoria de GPU para que el conjunto KV de prellenado tuviera ahora capacidad para unos 2.04 millones de tokens, aproximadamente el doble de la longitud de contexto de 1,048,576 tokens. Así, toda instrucción que cabe en la ventana de contexto también cabe en el conjunto. El parche del motor retira de la cola de admisión de la desagregación las solicitudes pendientes de rechazo, junto con su error original, antes de que se produzca cualquier inicialización, asignación o transferencia KV. Antes de restablecer el modelo, Cloudflare validó ambos cambios con el script de reproducción del investigador y con sus propias pruebas de marcadores canario.

Correcciones incorporadas al proyecto y trabajo en curso

Cloudflare propuso su corrección al proyecto SGLang mediante la solicitud de incorporación de cambios n.º 38704. Los mantenedores incorporaron la n.º 38935, que rechaza las solicitudes afectadas en la fase de admisión siguiendo el enfoque de Cloudflare. Una corrección relacionada, la n.º 36988, se había incorporado el 6 de septiembre de 2026 para una ruta de fallo relacionada. El parche se publicó en SGLang v0.5.20, seguido de cambios en v0.5.21, publicada el 2 de octubre de 2026, y v0.5.22, publicada el 19 de octubre de 2026. Cloudflare recomienda que todos los operadores de SGLang actualicen a v0.5.22 o una versión posterior. El equipo de SGLang señala que v0.5.21 protege de forma predeterminada las implementaciones de Mooncake y NIXL frente a todos los tipos de fallo, que las implementaciones de MORI requieren una compilación de v0.5.22 y que la serie de correcciones no se incorporó a las ramas de versiones anteriores.

El equipo de SGLang informó que, en 21 ejecuciones en dos GPU H100, las variaciones del rendimiento con las protecciones se mantuvieron dentro de ±2 %, y todos los intervalos de confianza del 95 % incluyeron el cero. También indicó que, en una prueba independiente de 16 ejecuciones en dos GPU H200, el costo de habilitar por defecto la liberación diferida de KV fue de −0,38 %, con un intervalo de confianza de −2,12 % a +1,36 %, que describió como no significativo. Cloudflare se reunió con los responsables de mantenimiento de SGLang en RadixArk el 10 de septiembre de 2026, implementó medidas de refuerzo adicionales en todos sus despliegues de SGLang en producción entre el 11 y el 19 de septiembre de 2026, y las fusiones al repositorio principal que abarcan la corrección de admisión, las sumas de verificación por transferencia, la preservación de las confirmaciones de cancelación y la liberación diferida de KV habilitada por defecto se realizaron entre el 16 de septiembre y el 12 de octubre de 2026.

Para otros operadores que ejecutan SGLang en modo desagregado, el informe de Cloudflare recomienda medir el pool de KV en relación con la longitud del contexto en cada nodo de prefill y decode después de cualquier cambio en los pesos, la cuantización, el paralelismo o la fracción de memoria; actualizar a una compilación que incluya ambas correcciones de admisión; ejecutar ambos roles con la liberación diferida de KV habilitada; activar la detección de corrupción cuando el modelo la admita; y configurar los balanceadores de carga para que la desconexión de un cliente no interrumpa una solicitud a mitad de la transferencia.

Cloudflare afirmó que anteriormente había creado un diseño prototipo que etiqueta cada página física de KV y comprueba la correspondencia antes de que decode lea la caché, y que en las pruebas su costo fue inferior al 1 % en rendimiento y latencia de cola. La empresa probó el prototipo con GLM 5.2 a mediados de agosto de 2026, pero lo deshabilitó poco después debido a problemas de fiabilidad. Cloudflare está trabajando con el equipo de SGLang en una versión de producción integrada en el motor; la suma de verificación por transferencia incluida en la solicitud de incorporación de cambios #39500 es un primer paso. También afirmó que está aplicando su experiencia en métodos formales a modelar y demostrar la seguridad de un protocolo de transferencia de caché KV basado en RDMA que utiliza Mooncake en su despliegue de SGLang en producción.

La publicación del equipo de SGLang agradece a los ingenieros de Cloudflare Kevin Flansburg y Kastan Day su trabajo en las correcciones, y señala la divulgación coordinada de SGLang y Cloudflare del 26 de octubre de 2026 como la última entrada de su cronología de divulgación. El informe del propio investigador, que, según indicó el equipo de SGLang, describirá el descubrimiento y la validación externa, está pendiente de publicación.