Cloudflare corrige una fuga de datos entre solicitudes en el motor de inferencia GLM-5.3

Cloudflare reveló un incidente de seguridad en su plataforma Workers AI, donde el modelo GLM-5.3 devolvió inadvertidamente datos de las solicitudes de otros usuarios. La vulnerabilidad, activa del 27 de agosto al 9 de septiembre de 2026, afectó a 155 respuestas y fue desencadenada por prompts específicos de contexto largo. Cloudflare ha parcheado desde entonces el motor de inferencia subyacente y restauró el modelo con controles de seguridad mejorados.

Qué ocurrió

El 8 de septiembre de 2026, el investigador de seguridad Gadi Evron informó que el modelo @cf/zai-org/glm-5.3 en Workers AI estaba filtrando datos de sesión. Cloudflare reprodujo el problema a la mañana siguiente y sacó el modelo de línea en 40 minutos. La investigación reveló que, entre el 27 de agosto y el 9 de septiembre, un pequeño número de clientes recibió respuestas que contenían texto de solicitudes realizadas por otros clientes al mismo modelo poco antes de las suyas. Las 155 respuestas afectadas fueron generadas a partir de prompts que superaban los 681.280 tokens. Cloudflare no encontró evidencia de explotación deliberada, señalando que los patrones de solicitud coincidían con el uso normal de contextos largos, en lugar de ataques dirigidos.

La causa raíz fue una combinación de un error de configuración y un bug en SGLang, el motor de inferencia de código abierto que impulsa el servicio. Cloudflare había desplegado GLM-5.3 con una ventana de contexto de 1.048.576 tokens, pero el pool de caché Key-Value (KV) en las GPUs de prefill solo podía contener 681.280 tokens. Aunque el equipo era consciente de esta discrepancia, asumieron que el motor devolvería un error para prompts que no cupieran. En cambio, el motor intentó procesar la solicitud utilizando una ruta de rechazo defectuosa, lo que llevó a la exposición. Ningún otro modelo alojado en Workers AI se vio afectado porque sus pools KV eran más grandes que sus respectivas longitudes de contexto.

Cómo funciona

Workers AI sirve GLM-5.3 utilizando una arquitectura desagregada donde las GPUs de prefill procesan los prompts y generan cachés KV, que luego se transfieren mediante acceso directo a memoria remota (RDMA) a las GPUs de decodificación para la generación de respuestas. La caché KV se almacena en un pool compartido de páginas de tamaño fijo en la memoria de la GPU. Para mantener un alto rendimiento, estas páginas no se ponen a cero entre solicitudes; el motor depende de un seguimiento estricto de la propiedad para garantizar que una nueva solicitud sobrescriba cualquier dato anterior en sus páginas asignadas.

Cuando un prompt excedía el tamaño del pool KV, el planificador de SGLang marcaba la solicitud como rechazada, pero la reemplazaba con un marcador de posición de un token para permitir que drenara a través de la maquinaria de lotes. En una configuración de nodo único, esto resultaría en un error. Sin embargo, en la configuración desagregada, las colas de admisión verificaban si una solicitud estaba "finalizada" en lugar de "rechazada". Dado que la solicitud rechazada no estaba marcada como finalizada, fue admitida en el nodo de prefill. El nodo de prefill generó una caché para el marcador de posición de un solo token y la transfirió al nodo de decodificación. El nodo de decodificación, esperando una transferencia completa, retuvo las páginas reservadas restantes que aún contenían datos obsoletos de usuarios anteriores. Como consecuencia, la respuesta final incluía texto coherente generado a partir del marcador de posición mezclado con datos filtrados de las páginas de caché obsoletas.

Detalles clave

• Modelo afectado: Solo @cf/zai-org/glm-5.3 se vio impactado; todos los demás modelos de Workers AI permanecieron seguros.
• Ventana de exposición: La vulnerabilidad estuvo presente desde el 27 de agosto de 2026 hasta que el modelo fue sacado de línea el 9 de septiembre de 2026.
• Alcance del impacto: Exactamente 155 respuestas se vieron afectadas, todas originadas por prompts de más de 681.280 tokens.
• Causa raíz: Una discrepancia entre la ventana de contexto de 1.048.576 tokens y el pool de caché KV de 681.280 tokens, combinada con un bug en el manejo de solicitudes rechazadas por SGLang en modo desagregado.
• Remediación: Cloudflare aumentó el tamaño del pool KV a aproximadamente 2,04 millones de tokens y parcheó SGLang para abortar correctamente las solicitudes rechazadas antes de la transferencia KV.
• Correcciones upstream: Los mantenedores de SGLang fusionaron varios parches, incluyendo PR #38704 y #38935, y lanzaron las versiones v0.5.21 y v0.5.22 para abordar el problema para todos los usuarios.

Por qué importa

Este incidente destaca la fragilidad de la seguridad de memoria en motores de inferencia LLM de alto rendimiento. A medida que los proveedores impulsan ventanas de contexto más grandes y mayor throughput, a menudo adoptan arquitecturas complejas como prefill y decodificación desagregados. Estos sistemas dependen de una gestión precisa del estado a través de múltiples nodos. Cuando valores de configuración como la longitud de contexto y el tamaño del pool de memoria no se aplican estrictamente, los casos límite pueden llevar a graves vulnerabilidades de seguridad. Para los equipos de ingeniería que construyen sobre estas plataformas, subraya la importancia de entender que optimizaciones de rendimiento como la reutilización de memoria no puesta a cero vienen con una responsabilidad significativa para el proveedor de infraestructura.

Para los desarrolladores que utilizan Workers AI o servicios similares, este evento sirve como recordatorio de que el aislamiento de inquilinos no es solo una preocupación a nivel de red, sino también un desafío de gestión de memoria dentro del propio motor de inferencia. Si bien la rápida respuesta de Cloudflare limitó la exposición, el hecho de que 155 usuarios recibieran datos filtrados indica que incluso breves ventanas de vulnerabilidad pueden tener consecuencias tangibles. También demuestra el valor de la divulgación coordinada y la colaboración de código abierto, ya que las correcciones desarrolladas por Cloudflare se fusionaron upstream para beneficiar a la comunidad más amplia de SGLang.

Qué puedes hacer

• Actualiza SGLang: Si operas tu propia infraestructura de inferencia usando SGLang, actualiza inmediatamente a la versión v0.5.22 o posterior para incorporar los últimos parches de seguridad.
• Valida configuraciones: Asegúrate de que el tamaño de tu pool de caché KV sea estrictamente mayor que la longitud máxima de contexto para cada modelo que despliegues. No confíes en que el motor maneje elegantemente las discrepancias.
• Monitorea anomalías: Implementa registro y monitoreo de tiempos de respuesta y conteos de tokens. Las respuestas que llegan inesperadamente rápido para prompts largos pueden indicar procesamiento truncado o errores de caché.
• Revisa configuraciones desagregadas: Si utilizas arquitecturas de prefill/decodificación desagregadas, verifica que las rutas de rechazo se manejen correctamente a través de los nodos y que las solicitudes rechazadas no procedan a la transferencia KV.
• Verifica issues upstream: Revisa regularmente los rastreadores de problemas de los motores de inferencia de los que dependes, como SGLang, en busca de bugs conocidos de seguridad de memoria y condiciones de carrera.
• Audita el uso de contexto largo: Si tu aplicación depende de ventanas de contexto muy largas, realiza pruebas de integración específicas que validen la coherencia de salida y el aislamiento bajo carga, en lugar de simplemente verificar códigos de estado HTTP.