Cloudflare afirma que un fallo que afectaba a su modelo GLM-5.3 en Workers AI expuso datos de las solicitudes de algunos clientes a otros entre el 27 de agosto y el 9 de septiembre de 2026. La empresa identificó 155 respuestas afectadas, todas generadas a partir de indicaciones de más de 681.280 tokens, y no encontró indicios de que el problema se hubiera explotado deliberadamente.
El problema salió a la luz después de que el investigador de seguridad Gadi Evron, de Knostic, lo comunicara a través del programa HackerOne de Cloudflare el 8 de septiembre. Cloudflare reprodujo el problema a la mañana siguiente, desconectó el modelo en los 40 minutos posteriores a declarar un incidente y lo restableció más tarde ese mismo día, tras implementar correcciones en la configuración y el motor. La empresa indicó que ningún otro modelo alojado en Workers AI se vio afectado.
Cloudflare atribuyó la exposición a dos problemas. GLM-5.3 estaba configurado con una ventana de contexto de 1.048.576 tokens, pero el grupo de caché KV de sus GPU de prellenado solo podía contener 681.280 tokens. Por separado, SGLang, el motor de inferencia utilizado para servir el modelo, gestionaba incorrectamente las solicitudes que superaban la capacidad del grupo en su configuración de prellenado y decodificación desagregados.
En lugar de detener una solicitud demasiado grande y devolver un error, la ruta afectada de SGLang sustituía la indicación por un marcador de posición de un token. A continuación, la etapa de prellenado transfería los datos de caché correspondientes a ese marcador, mientras que la etapa de decodificación daba por completada la transferencia y leía el conjunto completo de páginas reservadas para la solicitud original. La mayoría de esas páginas no se había sobrescrito y aún contenía datos de solicitudes anteriores, que podían aparecer entonces en la respuesta.
Cloudflare modificó la configuración para que el grupo de caché KV de prellenado pueda contener unos 2,04 millones de tokens, aproximadamente el doble de la longitud de contexto del modelo. También aplicó un parche a SGLang para retirar las solicitudes rechazadas antes del inicio, la asignación de memoria o la transferencia de KV, y añadió una comprobación para verificar que el número de tokens transferidos coincida con la cantidad reservada por la decodificación. La empresa afirma que probó los cambios con el script de reproducción del investigador y sus propias pruebas con marcadores canario antes de restablecer el modelo.
El incidente también impulsó la implementación de medidas de protección más amplias en los despliegues de SGLang de Cloudflare, entre ellas comprobaciones para garantizar que la capacidad del grupo supere la longitud de contexto y medidas para reducir los riesgos derivados de las transferencias de caché KV y la reutilización de páginas. Cloudflare recomienda a los operadores que utilicen SGLang desagregado actualizar a la versión 0.5.22 o posterior, o aplicar retroactivamente las correcciones pertinentes. La empresa señaló que las correcciones para el incidente y otros problemas relacionados con la caché se han incorporado al repositorio principal, y que la mayoría están incluidas en SGLang 0.5.22.
Fuentes: Cloudflare Blog.