Cloudflare publicó el 26 de octubre de 2026 un informe sobre exposición de datos entre solicitudes del modelo @cf/zai-org/glm-5.3 en Workers AI. El incidente ocurrió entre el 27 de agosto y el 9 de septiembre; la empresa corrigió el problema y restauró el modelo el 9 de septiembre. La novedad es la divulgación técnica, no una brecha recién abierta en octubre.
Qué alcance declara Cloudflare
Según el informe original, hubo 155 respuestas afectadas, todas asociadas a entradas de más de 681.280 tokens. Podían contener datos de solicitudes recientes de otros clientes del mismo modelo. Cloudflare afirma que ningún otro modelo alojado en Workers AI estuvo afectado y que no encontró evidencia de explotación deliberada. Esta última afirmación no equivale a demostrar que una explotación fuera imposible.
La causa combinaba una configuración de contexto mayor que la capacidad de la caché y un fallo al gestionar solicitudes rechazadas. En la arquitectura utilizada, unas GPU preparaban el contexto y otras generaban la respuesta. Una transferencia incompleta podía dejar accesible estado de solicitudes anteriores. La reparación combinó más capacidad de caché y cambios en el motor de inferencia.
No es una memoria aprendida por el modelo
La caché de claves y valores, o KV, conserva estado temporal de atención durante la inferencia. Conviene distinguir esa capa de los pesos aprendidos durante el entrenamiento o de una memoria persistente diseñada por una aplicación.
Nuestra lectura es que evaluar únicamente la calidad del texto deja fuera una condición esencial de un servicio compartido: de qué solicitud procede la información utilizada. Una respuesta fluida puede ser un fallo grave si mezcla datos de dos clientes. El informe tampoco permite atribuir este defecto a los pesos de GLM ni a cualquier instalación de SGLang, el motor utilizado por Cloudflare.
Los parches no tienen todos el mismo papel
El cambio de SGLang #36988, integrado el 6 de septiembre, describe cómo retirar resultados de preparación abortados y liberar sus recursos. El cambio #38935 adelanta el rechazo a las puertas de admisión del sistema distribuido.
Hay un matiz relevante en la descripción actual de #38935: lo caracteriza como una mejora de uso de recursos y latencia, y aclara que los síntomas antiguos de caché obsoleta no se reproducen en la rama principal con #36988. Por eso no debe atribuirse toda la corrección al segundo parche.
Cloudflare recomienda a operadores de SGLang con preparación y generación separadas revisar capacidad y contexto tras los cambios, incorporar las correcciones y comprobar la compatibilidad de los controles de corrupción. Es una orientación para esa arquitectura; no una garantía de seguridad obtenida solo al cambiar de versión.
Cómo convertir el caso en una comprobación útil
Ejemplo hipotético, no ejecutado por Puntoes: en un entorno aislado y autorizado, dos clientes sintéticos usan marcadores distintos. Si una solicitud del segundo supera el límite permitido, el resultado esperado sería un error sin información del primero. También interesan las cancelaciones y los fallos de transferencia, no solo las respuestas normales.
Un consumidor de la API no administra necesariamente ese motor. Su siguiente paso sería contrastar con el proveedor la afectación concreta, sin asumir por este artículo que sus datos fueron expuestos.
El antecedente sobre aislamiento de entornos de entrenamiento de OpenAI trata otra capa y otro incidente. Ambos ayudan a formular preguntas de control; no permiten comparar la seguridad de los proveedores. Puntoes no ha reproducido esta vulnerabilidad ni auditado la infraestructura de Cloudflare.