Cloudflare reveló el 26 de octubre de 2026 un fallo de aislamiento entre clientes en el modelo GLM-5.3 alojado en Workers AI. Según el informe oficial de la empresa, 155 respuestas contenían datos de solicitudes de otros clientes entre el 27 de agosto y el 9 de septiembre de 2026. Todas las respuestas afectadas correspondían a prompts de más de 681.280 tokens.
Este tema se clasifica aquí como CONFIRMADO porque se basa en una divulgación oficial. No afectó a prompts comunes. Cloudflare afirma que ningún otro modelo de Workers AI resultó afectado y que no encontró evidencia de explotación deliberada. La empresa solo habla de un "pequeño número de clientes" afectados, sin indicar cuántos fueron.
Cómo se sumaron dos fallos
La primera causa fue una configuración incompatible: GLM-5.3 se lanzó con una ventana de contexto de 1.048.576 tokens, pero el pool de caché KV de las GPU de prefill solo admitía 681.280 tokens. Cloudflare dice que ya conocía esa diferencia y esperaba que el motor devolviera un error para los prompts que no cupieran en el pool.
La segunda causa fue un error en SGLang, el motor de inferencia de código abierto usado por la plataforma, en el modo desagregado de prefill y decode. Un prompt demasiado largo se marcaba internamente como rechazado y se sustituía por un marcador de un solo token, pero, en lugar de interrumpir la solicitud con un error, el sistema continuó. El nodo de decode recibió la señal de transferencia completada y generó la respuesta leyendo páginas de caché que aún guardaban datos de solicitudes anteriores. El cliente recibía HTTP 200, y no HTTP 400, con una respuesta de apariencia coherente.
Cronología y corrección
El investigador Gadi Evron, de Knostic, informó del problema el 8 de septiembre de 2026 a través del programa HackerOne de Cloudflare. El 9 de septiembre, la empresa declaró el incidente, retiró el modelo en un plazo de 40 minutos tras la declaración y lo restauró el mismo día, ya con la configuración corregida y el motor corregido.
En la corrección, el pool de prefill pasó a admitir unos 2,04 millones de tokens, aproximadamente el doble de la ventana de contexto. Cloudflare también corrigió la ruta de rechazo en el motor y recomienda que todos los operadores actualicen SGLang a la versión 0.5.22 o posterior. La corrección principal llegó a SGLang 0.5.20, con continuaciones en las versiones 0.5.21 y 0.5.22.
Por qué importa
El caso muestra un riesgo práctico de la inferencia compartida a gran escala: la caché KV es una frontera de aislamiento entre clientes, y no solo un detalle de rendimiento. Cuando el tamaño del pool y el de la ventana de contexto no se verifican juntos, y la ruta de error no se prueba con la salida real del modelo, un fallo puede parecer un éxito, con código 200 y un recuento de tokens plausible.
Para los equipos que operan SGLang por su cuenta, la lección directa es verificar el tamaño del pool de KV frente a la ventana de contexto en cada cambio de despliegue y mantener el motor actualizado. Para quienes usan API alojadas, el episodio refuerza la prudencia con datos sensibles en prompts muy largos, incluso cuando la respuesta parece normal.
Crédito de la imagen: diagrama publicado por Cloudflare en su informe oficial sobre la exposición de la caché KV en GLM-5.3.
Fuentes
- Cloudflare — Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang
- Unite.AI — Cloudflare Says GLM-5.3 Bug Leaked 155 Responses Across Tenant Sessions
- AICoder — Cloudflare discloses a cross-request KV cache leak in GLM-5.3 on Workers AI
Transparencia: este artículo se produjo con ayuda de inteligencia artificial, a partir de investigación en fuentes públicas de internet, incluido el informe oficial de Cloudflare. Consulte las fuentes originales enumeradas arriba antes de tomar decisiones técnicas.
Muse
