Un fallo de caché de Cloudflare mezcló datos de distintos clientes en el modelo GLM-5.3

Cloudflare ha contado este lunes 26 de octubre en su blog que, entre el 27 de agosto y el 9 de septiembre, un pequeño número de clientes que usaban el modelo GLM-5.3 de Workers AI recibió respuestas con datos de peticiones que otros clientes habían hecho al mismo modelo poco antes. En total fueron 155 respuestas, todas a instrucciones (prompts) de más de 681.280 tokens. La compañía afirma que no encontró indicios de explotación deliberada y que ningún otro modelo de Workers AI se vio afectado.

---

Qué pasó y a quién afectó

GLM es un modelo de generación de texto de Z.ai pensado para programar con agentes, y es uno de los muchos modelos disponibles en Workers AI. El problema solo aparecía con instrucciones muy largas: cuando una superaba los 681.280 tokens, la respuesta podía incluir texto de las sesiones de otros usuarios de GLM-5.3. Estuvo presente desde el lanzamiento del modelo en Workers AI, el 27 de agosto. Según la compañía, una vez descartadas sus propias pruebas y las del investigador que dio el aviso, las peticiones afectadas encajan, por momento y por volumen, con un uso normal de contextos largos y no con alguien que aprovechara el fallo una y otra vez.

---

Quién lo avisó y cuánto tardaron en retirarlo

El aviso llegó el 8 de septiembre por el programa de HackerOne de la compañía. Lo envió Gadi Evron, investigador de seguridad de Knostic, con un guion que permitía reproducir el problema. La compañía lo reprodujo a la mañana siguiente y retiró el modelo en los 40 minutos posteriores a declarar el incidente. Después desplegó una configuración corregida y una versión parcheada del motor de inferencia, las comprobó con el guion del investigador y con sus propias pruebas, y volvió a abrir el modelo al público ese mismo 9 de septiembre.

---

Por qué ocurrió

Workers AI sirve GLM-5.3 con SGLang, un motor de inferencia de código abierto, repartido en dos grupos de GPU: uno procesa la instrucción y genera para ella la caché KV del modelo, y se la pasa al otro, que escribe la respuesta. Esa caché es un conjunto compartido de páginas de tamaño fijo: cada petición recibe páginas al entrar y las libera al terminar, y las páginas no se borran entre una petición y la siguiente, sino que la nueva escribe encima.

El incidente fue la suma de dos problemas. El primero, de configuración: GLM-5.3 se desplegó con una ventana de contexto de 1.048.576 tokens, pero la caché del primer grupo solo tenía sitio para 681.280. La compañía conocía el desajuste, pero esperaba que el motor devolviera un error con lo que no pudiera procesar, y sus pruebas con contextos largos daban respuestas correctas. Reconoce que esas pruebas solo miraban los códigos de respuesta y el rendimiento, sin validar el contenido ni la coherencia de lo que devolvía el modelo.

El segundo, un error de SGLang en este modo repartido. Una instrucción que no cabía se marcaba como rechazada y se cambiaba por otra de un solo token; en lugar de cancelar la petición y devolver un error, el primer grupo generaba la caché de esa instrucción mínima y se la pasaba al segundo, que daba por hecho que se había escrito la instrucción completa. La mayor parte de las páginas seguía guardando lo que habían dejado peticiones anteriores, y la respuesta se generaba leyéndolas: el cliente recibía un HTTP 200, en lugar de un HTTP 400, con contenido de otros usuarios.

---

Qué ha cambiado

La caché del primer grupo tiene sitio desde entonces para unos 2,04 millones de tokens, aproximadamente el doble de la ventana de contexto, así que cualquier instrucción válida cabe. Además, el motor parcheado retira una petición rechazada con su error antes de pasar nada al segundo grupo. La compañía ha aplicado el arreglo y el resto de medidas de refuerzo a todos los modelos que sirve con SGLang, y antes de cualquier cambio de despliegue comprueba el tamaño de la caché frente a la ventana de contexto.

El arreglo salió en SGLang v0.5.20, con continuaciones en v0.5.21 y v0.5.22, y la compañía recomienda a quien use el motor que actualice a v0.5.22 o posterior. El equipo de SGLang en RadixArk ha publicado su propia entrada sobre el fallo, como parte de la divulgación coordinada. A más largo plazo, la compañía trabaja con ese equipo para que el motor detecte, en el momento de leer, que una petición va a usar una página que no es suya, y falle solo esa petición en lugar de devolver datos de otro.

El 15 de octubre contamos cómo la compañía y OpenAI llevan cientos de millones de páginas nuevas al buscador de ChatGPT.

---

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.

---

Escrito por Eloy Andrade