Ciberseguridad
Cloudflare: su caché KV coló datos ajenos en 155 respuestas
Cloudflare, empresa estadounidense de red y seguridad web, publicó el 26 de octubre de 2026 el informe de un fallo de su servicio Workers AI que estuvo activo del 27 de agosto al 9 de septiembre. Según la empresa, el modelo GLM-5.3 devolvió en 155 respuestas fragmentos de peticiones de otros clientes, porque su caché KV reutilizaba memoria y un error del motor SGLang dejaba leer páginas ajenas. El fallo está corregido desde el 9 de septiembre; lo nuevo son las causas, los parches y la recomendación para quien usa SGLang.
Recibe el resumen diario de IA
Cada mañana, lo esencial de la inteligencia artificial en tu correo, sin humo. Al día con la IA.
Al suscribirte aceptas recibir el newsletter de AI Informator. Puedes darte de baja cuando quieras.
En resumen
- Según Cloudflare, entre el 27 de agosto y el 9 de septiembre de 2026, 155 respuestas del modelo GLM-5.3 en Workers AI incluyeron datos de otras peticiones, todas a prompts de más de 681.280 tokens.
- Cloudflare afirma que no encontró indicios de explotación deliberada y que ningún otro modelo de Workers AI quedó afectado.
- Según Cloudflare, la memoria reservada para la caché KV era más pequeña que la ventana de contexto anunciada, y un error de SGLang convirtió ese desajuste en una fuga.
- Cloudflare reconoce que sus pruebas previas al lanzamiento solo comprobaron los códigos HTTP y el rendimiento, no el texto que devolvía el modelo.
- Cloudflare recomienda a quien sirva modelos con SGLang actualizar a la versión 0.5.22 o posterior.
Un servicio de IA que devolvía restos de otras conversaciones
Workers AI es el servicio de Cloudflare para ejecutar modelos de IA en su propia red. Uno de ellos es GLM-5.3, un modelo de generación de texto de Z.ai que, según Cloudflare, está pensado para flujos de trabajo de programación con agentes. Cloudflare lo publicó en Workers AI el 27 de agosto de 2026 y, según su informe, la exposición existía desde ese mismo día.
El 8 de septiembre, el investigador de seguridad Gadi Evron, de la empresa de seguridad Knostic, avisó a través del programa de Cloudflare en HackerOne, la plataforma de recompensas por vulnerabilidades. Según Cloudflare, el aviso decía que los prompts muy largos enviados a GLM-5.3 devolvían a veces texto de sesiones de otros usuarios.
Según Cloudflare, su equipo reprodujo el fallo a la mañana siguiente con dos cuentas independientes en 25 minutos, retiró el modelo en menos de 40 minutos desde que declaró el incidente y lo restableció el 9 de septiembre con una configuración corregida y un motor parcheado.
El balance que da la empresa es de 155 respuestas afectadas, todas a prompts de más de 681.280 tokens. Según Cloudflare, un pequeño número de clientes recibió en ese periodo respuestas con datos de peticiones al mismo modelo hechas poco antes. Descontadas sus propias pruebas y las del investigador, Cloudflare sostiene que esas peticiones encajan en tiempo y volumen con un uso normal de contextos largos y que no halló indicios de explotación deliberada.
La ventana anunciada no cabía en la memoria reservada
Ver los datos en tabla
| Ventana de contexto anunciada | Reserva de caché KV en el lanzamiento | Reserva de caché KV tras el arreglo | |
|---|---|---|---|
| Tokens | 1.048.576tokens | 681.280tokens | 2.040.000tokens |
La primera causa, según Cloudflare, fue de configuración. GLM-5.3 se anunció con una ventana de contexto de algo más de un millón de tokens, pero la reserva de caché KV en las GPU que procesan el prompt era bastante más pequeña. Cualquier petición que pasara de esa reserva quedaba fuera de la memoria disponible aunque respetara la ventana anunciada.
Cloudflare reconoce que conocía el desajuste antes del lanzamiento. Según su informe, esperaba que el motor devolviera un error ante cualquier prompt que no pudiera procesar, y como sus pruebas de contexto largo recibían respuestas HTTP correctas, no lo consideró un problema.
Un error de SGLang convirtió el rechazo en una respuesta válida
La segunda causa, según Cloudflare, fue un fallo de SGLang, el motor de inferencia de código abierto que usa la empresa, cuando funciona con prefill y decode separados. El prompt que no cabía se marcaba como rechazado y se sustituía por un marcador de un solo token. En lugar de abortar la petición, la máquina de prefill calculaba la caché de ese token y se la entregaba a la de decode.
La máquina de decode creía haber recibido la petición completa y generaba la respuesta leyendo páginas de memoria antiguas, que aún guardaban datos de peticiones anteriores de otros usuarios. Según Cloudflare, el cliente recibía un código HTTP 200, el de una petición atendida con éxito, en lugar de un 400, el que señala una petición errónea, y además una respuesta coherente.
El fallo era posible porque, según Cloudflare, las páginas de la caché KV no se ponen a cero entre peticiones. La empresa explica que es una práctica común por rendimiento y que obliga al motor a llevar la cuenta de a quién pertenece cada página.
Dos arreglos y una prueba que no leía las respuestas
Según Cloudflare, el arreglo de configuración amplió la reserva de prefill a unos 2,04 millones de tokens, aproximadamente el doble de la ventana de contexto. Con eso, un prompt que cabe en la ventana cabe siempre en la memoria reservada.
El arreglo del motor retira las peticiones rechazadas antes de reservar memoria o transferir nada entre máquinas. Según Cloudflare, los parches están publicados en SGLang desde la versión 0.5.20, y la empresa pide expresamente a quien use este motor que actualice a la 0.5.22 o posterior.
El fallo no era desconocido. Según Cloudflare, otro usuario lo había comunicado a SGLang como incidencia #30233 el 6 de julio de 2026, y la empresa lo vio durante su investigación.
La autocrítica de Cloudflare apunta a sus pruebas previas al lanzamiento: «solo validamos los códigos de respuesta HTTP y el rendimiento del motor con contextos largos, sin validar la salida ni la coherencia del modelo». Según la empresa, ahora compara el tamaño de la reserva con la ventana de contexto antes de cada despliegue.
La solución de fondo: memoria con dueño
Según Cloudflare, el 10 de septiembre se reunió con el director técnico y con ingenieros de RadixArk, la empresa que mantiene SGLang. El informe del 26 de octubre se publica de forma coordinada con el investigador y con RadixArk.
La solución de fondo que prepara Cloudflare consiste en etiquetar cada página de la caché KV para que el motor detecte, en el momento de leerla, que una petición va a usar una página que no es suya. Según la empresa, su prototipo costó menos del 1 % de rendimiento, pero lo desactivó por problemas de fiabilidad.
Conclusión
Según Cloudflare, la fuga de GLM-5.3 en Workers AI nació de un desajuste conocido entre la ventana de contexto y la memoria reservada y de un error de SGLang que convertía un rechazo en una respuesta con datos ajenos. Lleva cerrada desde el 9 de septiembre, pero el aviso sigue vigente para cualquiera que sirva modelos con SGLang separando prefill y decode: actualizar a la versión 0.5.22 o posterior y comprobar el texto que devuelve el modelo, no solo el código HTTP. La pieza pendiente es que el propio motor sepa de quién es cada página de memoria antes de leerla.
Fuentes primarias
Recibe el resumen diario de IA
Cada mañana, lo esencial de la inteligencia artificial en tu correo, sin humo. Al día con la IA.
Al suscribirte aceptas recibir el newsletter de AI Informator. Puedes darte de baja cuando quieras.
Comentarios