01 · Contexto
Qué está ocurriendo
Cloudflare publicó el 26 de octubre un informe sobre exposición de datos entre solicitudes al modelo GLM-5.3 en Workers AI. Según el proveedor, el problema afectó 155 respuestas entre el 27 de agosto y el 9 de septiembre, exclusivamente ante prompts superiores a 681.280 tokens. El servicio fue corregido y restablecido el 9 de septiembre. La novedad es la divulgación técnica; no se trata de una exposición iniciada hoy.
El informe atribuye la falla a una combinación de configuración insuficiente del espacio de caché y manejo defectuoso de solicitudes rechazadas en SGLang. Una transferencia incompleta podía dejar datos anteriores disponibles para generar una respuesta. Cloudflare afirma que no encontró evidencia de explotación deliberada y que otros modelos no estuvieron afectados. Esa conclusión describe su investigación, no una garantía universal sobre cualquier instalación del motor.
02 · Impacto
Por qué importa
Análisis: este caso distingue dos propiedades que suelen mezclarse. Una respuesta puede ser válida en formato y exitosa para el monitoreo, pero utilizar información que no pertenece a quien la solicitó. La disponibilidad y la calidad aparente no demuestran confidencialidad. En servicios compartidos, el control debe cubrir la propiedad de los datos durante toda su vida útil, incluso cuando una operación se cancela o falla parcialmente. Para equipos que consumen IA como servicio, el aprendizaje no exige reproducir la infraestructura del proveedor. Exige preguntar qué se prueba, cómo se delimitó el impacto y qué evidencia permite verificar que la corrección cubre la causa, no únicamente el escenario conocido.
03 · Recomendaciones
Qué conviene hacer
- Como recomendación, identifique primero si utiliza el modelo y servicio indicados durante el período informado. Evite extrapolar el incidente a todos los modelos o asumir que cualquier respuesta propia estuvo afectada. Conserve los registros pertinentes y canalice preguntas al proveedor sin compartir prompts confidenciales en foros públicos. La revisión debe partir de exposición comprobable y de obligaciones internas aplicables, no de una alarma genérica.
- Si administra inferencia compartida, incluya pruebas autorizadas con datos sintéticos que distingan usuarios, cancelaciones, límites y reutilización de memoria. Defina como resultado esperado que una solicitud rechazada falle de manera segura, sin recuperar contenido de otra sesión. Revise la compatibilidad de las correcciones del motor antes de desplegarlas y registre versiones, configuración y resultados. Finalmente, añada estas verificaciones a los cambios de capacidad: aumentar contexto o modificar memoria también puede alterar supuestos de seguridad.