Cloudflare reveló que su plataforma Workers AI filtró datos entre sesiones de clientes en el modelo GLM-5.3 entre el 27 de agosto y el 9 de septiembre de 2026, con 155 respuestas afectadas antes de que la empresa retirara el modelo y publicara una corrección. El bug, detallado en un informe de remediación en el blog de Cloudflare, afectó únicamente a prompts de más de 681,280 tokens y fue reportado a través del programa HackerOne de Cloudflare por el investigador de seguridad Gadi Evron, de Knostic.

Workers AI sirve GLM-5.3 —un modelo de generación de texto de Z.ai diseñado para flujos de trabajo de codificación agéntica— a través de SGLang, un motor de inferencia de código abierto, en una configuración desagregada de prefill/decode. Un pool de GPUs de prefill procesa el prompt y construye la caché KV del modelo, y luego entrega esa caché vía RDMA mediante Mooncake a un pool separado de GPUs de decode que generan la respuesta. La caché KV misma reside en un pool compartido de páginas de memoria GPU de tamaño fijo que no se borran entre solicitudes; la siguiente solicitud que reclama una página simplemente la sobrescribe, lo cual es práctica estándar por rendimiento, pero traslada toda la carga de rastrear la propiedad de las páginas al motor de inferencia.

El propio informe de Cloudflare atribuye el incidente a dos fallas superpuestas. Primero, un desajuste de configuración: GLM-5.3 fue desplegado con una ventana de contexto de 1,048,576 tokens, pero el pool de caché KV en las GPUs de prefill de Cloudflare solo tenía espacio para 681,280 tokens —una brecha que, según la empresa, conocía antes del lanzamiento pero asumió que el motor manejaría correctamente, ya que las pruebas previas al lanzamiento devolvían códigos HTTP exitosos sin tramas de error. Segundo, un bug en la forma en que SGLang manejaba prompts de longitud excesiva en modo desagregado: cuando un prompt no cabía en el pool, el planificador debía rechazarlo, pero en su lugar lo reemplazaba con un marcador de posición de un solo token y lo dejaba fluir por el pipeline normal. El prefill generó una caché KV para ese marcador de posición y la transfirió al nodo de decode, que asumió que la transferencia había sobrescrito por completo los datos de la solicitud anterior. No fue así: el nodo de decode luego generó una respuesta mientras atendía páginas de caché obsoletas que aún contenían prompts y generaciones parciales de otros usuarios, devolviendo un HTTP 200 con texto coherente en lugar del error esperado.

La línea de tiempo del incidente de Cloudflare muestra que Seguridad de Producto reprodujo la filtración a los 25 minutos de declarar un incidente el 9 de septiembre, retiró el modelo de circulación en aproximadamente 40 minutos desde esa declaración, y lo restauró el mismo día tras desplegar una configuración corregida —elevando el pool de caché KV de prefill a aproximadamente 2.04 million tokens, cerca del doble de la longitud de contexto— junto con un motor parchado. La empresa dice que no encontró evidencia de explotación deliberada; las 155 respuestas afectadas fueron consistentes en tiempo y volumen con el uso habitual de contexto largo, una vez excluidas las pruebas propias de Cloudflare y los intentos de reproducción del investigador.

El bug subyacente de SGLang ya había sido reportado por otro usuario como el issue #30233 el 6 de julio de 2026, algo que Cloudflare dice haber notado mientras investigaba este incidente. La corrección para ese issue se incorporó en SGLang v0.5.20, con seguimientos en v0.5.21 y v0.5.22, y Cloudflare dice que ahora recomienda a todos los operadores de SGLang actualizar a v0.5.22 o posterior. Cloudflare también dice que ha extendido la liberación diferida de páginas KV para cubrir todo tipo de fallo en lugar de solo los abortos, que desplegó lotes de transferencia Mooncake acotados para que ninguna llamada de transferencia individual pueda superar un tiempo límite de liberación, y que modificó su balanceador de carga para que la desconexión de un cliente ya no aborte una solicitud a mitad de la transferencia.

Lo que sigue sin resolverse es estructural, no un parche. La publicación de Cloudflare afirma con claridad que las verificaciones de configuración y las correcciones de ciclo de vida "no hacen imposible el uso indebido", y que el prototipo de agosto de la empresa para el etiquetado de integridad a nivel de página —que costó menos de 1% en rendimiento y latencia de cola durante las pruebas— fue desactivado tras problemas de confiabilidad y está vinculado a backends de atención y arquitecturas de modelo específicas, por lo que aún no es una solución general. Cloudflare dice que ahora trabaja con los mantenedores de SGLang en RadixArk en una versión de producción de esa verificación de integridad, y por separado está aplicando métodos de verificación formal para modelar la seguridad de su protocolo de transferencia de caché KV basado en RDMA, un proyecto que describe como en curso y no concluido.

Para quienes operan cachés KV compartidas entre múltiples inquilinos, la lección es procedimental: Cloudflare dice que la brecha que pasó por alto fue validar únicamente los códigos de respuesta HTTP y el rendimiento en longitudes de contexto largas, no la corrección de la salida, y su propia recomendación a otros operadores de SGLang es medir el tamaño del pool KV frente a la longitud de contexto directamente desde el registro de arranque del motor en cada nodo de prefill y decode, después de cualquier cambio en los pesos, la cuantización o el paralelismo —no inferir seguridad a partir de un código de estado exitoso.