Cloudflare ha publicado un informe de incidente detallado que describe cómo un error en el manejo de caché en su plataforma de IA sin servidor provocó que al menos 155 usuarios de una implementación del modelo GLM-5.3 recibieran respuestas que contenían fragmentos de indicaciones y resultados de otros clientes. El informe, publicado el 26 de octubre como una divulgación coordinada junto con el proyecto del motor de inferencia de código abierto SGLang, ofrece una mirada pública poco común al interior del servicio LLM multiinquilino y una advertencia sobre los supuestos de seguridad de la memoria GPU.
Cómo se encontró la fuga Para más contexto sobre esta historia, consulta nuestra últimos avances en IA.
Según Cloudflare, el investigador de seguridad Gadi Evron de Knostic alertó a la empresa el 8 de septiembre de 2026 a través de su programa de recompensas por errores HackerOne. Evron informó que los mensajes muy largos enviados al modelo GLM-5.3 en la plataforma Workers AI de Cloudflare a veces devolvían texto que pertenecía a las sesiones de otros usuarios. Cloudflare reprodujo el problema a la mañana siguiente y desactivó el modelo el mismo día, restaurándolo el 9 de septiembre después de implementar las correcciones.
El modelo afectado fue @cf/zai-org/glm-5.3, el modelo de codificación agente de Z.ai que Cloudflare ofrece a través de Workers AI, la plataforma de inferencia sin servidor de la empresa. Cloudflare confirmó que ningún otro modelo alojado en la plataforma se vio afectado.
Lo que realmente pasó
El incidente se debe a dos problemas superpuestos, uno operativo y otro en el propio motor.
Primero, la mala configuración. Cloudflare implementó GLM-5.3 con una ventana de contexto de 1.048.576 tokens, pero el grupo de caché de valor clave (KV) en sus GPU precargadas solo tenía espacio para 681.280 tokens. La compañía reconoció que era consciente de esta discrepancia antes del lanzamiento y esperaba que el motor de inferencia rechazara de forma segura las solicitudes demasiado largas.
En segundo lugar, el error del motor. En el modo de precarga/decodificación desagregado (la arquitectura que utiliza Workers AI, en la que un grupo de GPU procesa el mensaje y entrega el caché KV resultante a un grupo separado de GPU que genera la respuesta), SGLang manejó la solicitud de longitud excesiva de manera incorrecta. Un mensaje que no encajaba en el grupo se marcaba internamente como rechazado y se reemplazaba con un marcador de posición de un token. Pero en lugar de abortar la solicitud y devolver un error del cliente, la etapa de prellenado generó un caché KV para el mensaje de marcador de posición y lo transfirió al nodo de decodificación, que luego produjo una respuesta que mezcló datos sobrantes de solicitudes anteriores que compartían las mismas páginas de memoria.
El resultado: entre el 27 de agosto y el 9 de septiembre, un pequeño número de clientes que utilizaron el modelo recibieron respuestas que contenían datos de las solicitudes de otros clientes realizadas poco antes que las suyas. En total, 155 respuestas se vieron afectadas; todas, según descubrió Cloudflare, a solicitudes de más de 681,280 tokens.
No hay evidencia de explotación deliberada
Cloudflare declaró que después de excluir sus propias pruebas y las solicitudes de validación del investigador, las solicitudes afectadas fueron consistentes en tiempo y volumen con el uso normal en contextos prolongados, y la compañía no encontró evidencia de que alguien explotara deliberadamente el error. Debido a que cada solicitud afectada excedía la capacidad del grupo de tamaño insuficiente, la ventana de exposición estaba estrictamente limitada, un lado positivo que surge de la misma mala configuración que causó el problema.
La solución: grupos más grandes y una ruta de falla más segura
La remediación funcionó en ambas capas de la falla. Cloudflare reconfiguró su implementación GLM-5.3 para que coincida con su configuración GLM-5.2, liberando suficiente memoria de GPU para que el grupo KV precargado ahora contenga alrededor de 2,04 millones de tokens, aproximadamente el doble de la longitud de contexto de 1.048.576 tokens del modelo. Un mensaje que se ajusta a la ventana de contexto ahora siempre se ajusta al grupo.
Pero la compañía también enfatizó que depender únicamente del tamaño del grupo es frágil: los cambios en la cuantificación, el paralelismo tensorial, los tamaños de los gráficos CUDA o una versión futura del modelo pueden cambiar silenciosamente el tamaño del grupo. Por lo tanto, también parchó la ruta de rechazo de SGLang, asegurando que una solicitud rechazada se cancele limpiamente en lugar de generar y transferir caché para un marcador de posición. Ambos cambios se validaron con el script de reproducción del investigador y las propias pruebas de marcadores canarios de Cloudflare antes de que se restaurara el modelo, y las correcciones se han aportado previamente a los mantenedores de SGLang.
Por qué la memoria GPU compartida es una cuestión de seguridad
El informe explica una práctica que sorprenderá a muchos desarrolladores de aplicaciones: los motores de inferencia generalmente no ponen a cero las páginas de caché KV entre solicitudes, porque la siguiente solicitud simplemente las sobrescribe. Se trata de una compensación deliberada del rendimiento, común en todos los motores de inferencia, pero como muestra este incidente, cualquier ruta que permita generar una respuesta antes de que esas páginas se sobrescriban por completo convierte una optimización del rendimiento en un vector de fuga de datos.
La revelación llegó a la comunidad de desarrolladores: la historia alcanzó 123 puntos en Hacker News en cuestión de horas, y la discusión se centró en cómo el modo de falla (una solicitud que debería haber fallado ruidosamente en lugar de proceder silenciosamente en un estado corrupto) refleja las lecciones clásicas de la ingeniería de sistemas distribuidos.
Una lección más amplia para la infraestructura de IA
El incidente es un recordatorio de que el perímetro de seguridad para las aplicaciones de IA ahora se extiende profundamente hacia la infraestructura de inferencia. El modelo de servicio multiinquilino concentra los datos de muchos clientes a través de aceleradores compartidos, grupos de caché compartidos y arquitecturas cada vez más exóticas, como precarga desagregada y acceso remoto directo a la memoria. Una sutil discrepancia entre la ventana de contexto anunciada de un modelo y la capacidad física aprovisionada para servirla fue suficiente para romper el aislamiento de los inquilinos.
Para las empresas que se basan en plataformas de IA sin servidor, la conclusión del informe de Cloudflare es doble: los errores de aislamiento de inquilinos en el servicio LLM son reales y ya han ocurrido en producción, y el tiempo de respuesta de los proveedores (menos de 24 horas desde el informe hasta la desactivación, un día para corregir y restaurar) es el estándar de diligencia que se debe exigir a cualquier proveedor que maneje avisos confidenciales.
---
Mantente al Día con la IALas últimas noticias, análisis y avances de inteligencia artificial, en un solo lugar.
Leer más noticias de IA →
