Cloudflare: GLM-5.3 expuso datos de 155 respuestas

Cloudflare: 155 respuestas mezclaron datos de otros clientes

Cloudflare confirmó que, entre el 27 de agosto y el 9 de septiembre de 2026, un grupo reducido de clientes del modelo GLM-5.3 en Workers AI recibió respuestas que contenían datos de peticiones de otros usuarios hechas al mismo modelo poco antes. Fueron 155 respuestas en total, todas a prompts de más de 681.280 tokens.

La cifra es pequeña y el umbral es alto, pero el tipo de fallo es lo que debería preocuparte: no hubo caída de servicio ni error visible, hubo fuga de contexto entre inquilinos. Y la causa no fue un atacante, sino una configuración propia sumada a un bug en el motor de inferencia de código abierto SGLang.

¿Qué pasó y cómo se detectó el fallo?

El 8 de septiembre de 2026, el investigador de seguridad Gadi Evron, de Knostic, envió el reporte por el programa HackerOne de Cloudflare: prompts muy largos enviados a @cf/zai-org/glm-5.3 devolvían a veces texto perteneciente a sesiones de otros usuarios.

Cloudflare reprodujo el problema a la mañana siguiente, declaró el incidente y retiró el modelo de circulación en 40 minutos. El mismo 9 de septiembre desplegó una configuración corregida junto a un motor parcheado y restauró el servicio. La exposición había estado presente desde el lanzamiento del modelo, el 27 de agosto de 2026.

Dos matices importan. Primero: Cloudflare afirma que no encontró evidencia de explotación deliberada; tras excluir sus propias pruebas y las del investigador, el volumen y la distribución temporal de las peticiones encajaban con uso normal de contexto largo. Segundo: GLM-5.3 fue el único modelo afectado en Workers AI, porque el resto de los despliegues en modo disagregado tienen pools de KV más grandes que su ventana de contexto.

Las dos causas: una configuración desajustada y un bug en SGLang

El fallo necesitó dos condiciones al mismo tiempo.

La configuración. Cloudflare desplegó GLM 5.3 con una ventana de contexto de 1.048.576 tokens, pero el pool de KV cache de sus GPUs de prefill solo tenía espacio para 681.280 tokens. La empresa conocía el desajuste antes del lanzamiento y asumió que el motor devolvería un error ante cualquier prompt que no pudiera procesar. Sus pruebas de contexto largo devolvían respuestas exitosas, así que no lo trató como un problema. SGLang calcula el tamaño del pool al arrancar, a partir de la memoria de GPU que queda libre tras cargar los pesos, y lo expone en los logs: nada obliga a que ese número coincida con la ventana de contexto.

El bug. En modo disagregado, prefill y decode corren en nodos distintos. Cuando llegaba un prompt más largo que el pool, SGLang lo marcaba como rechazado y lo sustituía internamente por un placeholder de un token. En un despliegue de un solo nodo eso funcionaba: el cliente recibía un error. En modo disagregado, las colas de admisión de prefill y decode comprobaban si una petición había terminado, no si había sido rechazada. Una petición rechazada seguía reportándose como viva.

El resultado fue una cadena silenciosa: prefill admitía la petición, ejecutaba un forward pass trivial sobre el token placeholder, transfería una sola página de KV a decode por RDMA vía Mooncake y avisaba de que la transferencia estaba completa. Decode había reservado 8 páginas (el ejemplo del diagrama que publicó Cloudflare), asumió que prefill las había sobrescrito todas y generó la respuesta leyendo las 7 restantes, que aún contenían prompts y generaciones parciales de otros usuarios. El cliente recibía un HTTP 200 en lugar de un HTTP 400, con prompt_tokens correcto y una respuesta coherente. Y llegaba más rápido de lo que debería tardar un prefill de 8 páginas.

Ese último detalle es el que más debería inquietar a un equipo de plataforma: el fallo no levantaba ninguna alarma.

¿Qué cambió en SGLang y qué versión debes usar?

Cloudflare atacó el problema por dos vías. Ajustó la configuración de GLM 5.3 para igualarla a la de GLM 5.2, lo que liberó memoria suficiente para que el pool de prefill pase a sostener unos 2,04 millones de tokens, aproximadamente el doble de la ventana de contexto. Así, un prompt válido nunca llega a la ruta de rechazo.

Pero como el tamaño del pool cambia con la cuantización, el paralelismo de tensores o el tamaño de los CUDA graphs, también parcheó el motor: una petición con rechazo pendiente se retira en la cola de admisión, con su error original, antes de cualquier bootstrap, asignación o transferencia de KV. Cloudflare propuso ese enfoque upstream y los mantenedores de SGLang lo adoptaron.

El bug había sido reportado antes a SGLang como issue #30233 el 6 de julio de 2026, y Cloudflare venía señalando este tipo de problemas desde la v0.5.10. El parche salió en SGLang v0.5.20, con seguimientos en v0.5.21 y v0.5.22. La recomendación de Cloudflare para cualquier operador que use SGLang en modo disagregado es actualizar a v0.5.22 o posterior.

¿Qué significa esto para tu startup?

Si construyes sobre una API gestionada, la lección no es cambiar de proveedor: es entender qué parte del stack no controlas y cómo verificarla. Si haces self-hosting o fine-tuning sobre infraestructura propia, hay trabajo concreto que hacer esta semana.

• Mide el pool de KV cache contra la ventana de contexto en cada nodo de prefill y decode, leyendo el log de arranque del motor, después de cada cambio de pesos, cuantización, paralelismo o fracción de memoria. Si el pool es menor, baja la ventana de contexto hasta que encaje. No delegues ese límite a un proxy.
• No valides solo códigos HTTP. El error de Cloudflare fue comprobar códigos de estado y rendimiento en contexto largo sin validar la coherencia de la salida. Añade canarios: inserta marcadores únicos en el prompt y verifica que aparezcan en la respuesta.
• Actualiza SGLang a v0.5.22 o superior si operas modo prefill/decode disagregado. Ese parche es el respaldo para el día en que tu propia comprobación esté mal.
• Activa la detección de corrupción donde tu modelo lo soporte. Cloudflare advierte que --disaggregation-enable-kv-checksum y --kv-canary todavía no cubren todas las arquitecturas: revisa los logs para confirmar que tus peticiones se están verificando.
• Revisa tu load balancer. Si un cliente se desconecta y eso aborta una petición a mitad de transferencia, se abre la puerta a escrituras tardías que aterrizan en el KV cache de otra petición. Configúralo para sostener la conexión hasta el primer token.

Vale la pena dimensionar por qué esto importa ahora. Workers AI es la plataforma de inferencia serverless sobre GPU que Cloudflare opera en su red global, y la compañía señaló al anunciar la incorporación de talento de Ensemble AI a su equipo de infraestructura de IA que el costo de inferencia sigue siendo una de las mayores barreras para escalar aplicaciones de IA, según recogió Pulse 2.0. Cuando el margen es tan ajustado, la tentación de optimizar memoria de GPU al límite es enorme. Este incidente es el recordatorio de que esa optimización tiene un costo que no aparece en la factura.

Del lado del modelo, el contexto ayuda a entender la presión. Z.ai publicó el 17 de septiembre de 2026 un informe técnico sobre cómo construyó un servicio de inferencia de producción para GLM-5.3-Flash —el primer modelo nativamente multimodal de la serie GLM-5, lanzado el 26 de agosto de 2026, con 320.000 millones de parámetros totales y 18.000 millones activos— sobre un clúster de más de 100.000 aceleradores de IA de fabricación china, según recogió Unite.AI. La serie GLM-5 apuesta por ventanas de contexto de un millón de tokens, y ahí está justamente la zona donde apareció el bug: cuanto más largo el contexto, más presión sobre el pool de KV.

¿Tu startup responde por los datos que filtra un modelo de terceros?

Sí, y esto es lo que suele pasarse por alto. Si un usuario de tu producto ve fragmentos de la sesión de otro, la conversación con ese usuario no empieza por «fue el motor de código abierto». Empieza por tu contrato, tu acuerdo de tratamiento de datos y, si operas en Europa, por tus obligaciones bajo el RGPD. El aislamiento multi-tenant es una promesa que vendes, no una característica que heredas de tu proveedor.

Cloudflare lo dice con claridad en su propio análisis: las comprobaciones de configuración y los parches de ciclo de vida reducen los caminos por los que una página de memoria puede usarse mal, pero no los eliminan. La respuesta durable, sostiene la compañía, es que el motor detecte en tiempo de lectura que una petición va a atender sobre una página que no le pertenece y falle esa petición en concreto. Cloudflare construyó un prototipo con etiquetas por página que, según sus pruebas, costaba menos de 1% en throughput y latencia de cola; lo probó en GLM 5.2 a mediados de agosto y lo desactivó poco después por problemas de fiabilidad.

¿Cómo detectar corrupción de KV cache antes de que llegue a tu usuario?

Las señales existen, pero hay que instrumentarlas. La primera es la coherencia: si tu aplicación no valida que la respuesta tenga relación con el prompt, un cruce de contexto pasa desapercibido. La segunda es la latencia: en este incidente, las respuestas afectadas llegaron más rápido de lo esperado, porque el nodo de decode leyó páginas que nadie había escrito para esa petición. Un pico anómalo de velocidad en contexto largo merece una revisión, no un festejo.

La tercera es el canario. Insertar marcadores únicos y comprobar su presencia en la salida es barato y detecta corrupción en producción, no solo en pruebas. Y la cuarta es mantener el motor actualizado: buena parte de los parches que Cloudflare describe son precisamente mecanismos de observabilidad, como el checksum por transferencia que verifica el handoff entre prefill y decode.

Conclusión

Un fallo de aislamiento de KV cache no es un incidente de disponibilidad, es un incidente de confianza. El de Cloudflare afectó a 155 respuestas en dos semanas y no tuvo señal visible: HTTP 200, respuesta coherente, entrega rápida. La parte alentadora es el resto del proceso: reporte con script reproducible, modelo fuera de circulación en 40 minutos, parches upstream coordinados con el equipo de SGLang y una v0.5.22 disponible para cualquier operador que quiera aplicarlos hoy.

Para un founder, la conclusión práctica cabe en una frase: si dependes de inferencia gestionada, exige a tu proveedor métricas de aislamiento y verifica la coherencia de las salidas desde tu propio código; si haces self-hosting, la comprobación de pool contra contexto debería estar en tu checklist de despliegue a partir de ahora.

Fuentes

• Cloudflare Blog (fuente original)
• Unite.AI
• Pulse 2.0

Artículos relacionados:

Cloudflare OS: la plataforma open source que democratiza agentes de IA en empresas Entre empresas europeas con CDN, 9 de cada 10 usan Cloudflare Cloudflare integra a Cursor en sus Sandboxes de IA Cloudflare Wallets: identidad y pagos para agentes de IA en 2026 Cloudflare OS: 10.000 horas ahorradas con IA interna en 2026