El fallo de Cloudflare Workers AI causó una filtración entre clientes que nadie vio venir en la pantalla: 155 respuestas del modelo GLM-5.3 contuvieron datos de peticiones de otros usuarios entre el 27 de agosto y el 9 de septiembre de 2026. Quien preguntó recibió un código de éxito, una respuesta coherente y, mezclado en el texto, material ajeno.
Cloudflare publicó la divulgación coordinada el 26 de octubre, junto al equipo de SGLang, el motor de código abierto que usa para servir modelos. El investigador Gadi Evron, de Knostic, avisó el 8 de septiembre por HackerOne. Al día siguiente la empresa reprodujo el problema en 25 minutos y retiró el modelo en 40 minutos.
Una memoria compartida que guardó lo ajeno
Para entender el fallo de Cloudflare Workers AI hay que mirar la memoria intermedia del modelo, la llamada caché KV. Esa memoria guarda en la tarjeta gráfica los cálculos parciales de cada petición, divididos en páginas de tamaño fijo. Las páginas no se borran entre peticiones por un motivo de rendimiento: la petición siguiente sobrescribe las que recibe.
Ese diseño funciona si el sistema controla con precisión qué página pertenece a cada cliente. En GLM-5.3 el control falló por dos piezas que encajaron mal. Cloudflare configuró el modelo con una ventana de contexto de 1.048.576 tokens, la unidad con la que estos sistemas miden el texto, pero el depósito de memoria de las tarjetas que leen la petición solo guardaba 681.280 tokens.
La empresa conocía esa diferencia antes del lanzamiento. Sus pruebas de contexto largo devolvían códigos de éxito y respuestas en flujo sin errores visibles, así que el equipo dio por hecho que el motor rechazaría lo que no cupiera. Cloudflare lo admite en su informe: revisó códigos y velocidad, no si el contenido de la respuesta tenía sentido.
En SGLang estaba la segunda pieza. Una petición más larga que el depósito quedaba marcada como rechazada y cambiada por un marcador de un solo token, para drenar por la maquinaria habitual. En un solo equipo ese camino terminaba en un error para el cliente. En el modo separado que usa Cloudflare, con un grupo de tarjetas que lee la petición y otro que genera la respuesta, la petición rechazada seguía viva para ambos grupos.
El grupo lector procesó ese token único y avisó de transferencia completa. El grupo generador había reservado páginas para la petición entera y leyó todas, aunque solo la primera traía datos nuevos. Las demás conservaban restos de peticiones anteriores: fragmentos de textos y de respuestas de otros clientes del mismo modelo, hechas poco antes.
155 respuestas y una ventana de 13 días
Todas las respuestas afectadas respondían a peticiones de más de 681.280 tokens, textos enormes, del tamaño de cientos de páginas. Cloudflare revisó los registros y, descontadas sus propias pruebas y las del investigador, encontró un patrón de uso ordinario de contexto largo, con tiempos y volúmenes normales. La empresa informó que no halló indicios de explotación deliberada.
GLM-5.3 fue el único modelo afectado de Workers AI, la plataforma de Cloudflare para ejecutar modelos de inteligencia artificial cerca del usuario. Los demás modelos servidos con la misma arquitectura tenían depósitos de memoria mayores que su ventana de contexto, así que ninguna petición suya podía entrar en la ruta del rechazo. Unite.ai recogió la misma cifra en su cobertura del 26 de octubre: 155 respuestas en 13 días.
La corrección llegó el mismo 9 de septiembre. Cloudflare amplió el depósito hasta unos 2,04 millones de tokens, el doble de la ventana anunciada, y parcheó el motor para que una petición rechazada se retire con su error original antes de cualquier transferencia entre tarjetas. El modelo volvió a estar público esa misma tarde, tras validar el arreglo con el guion de reproducción del investigador y con pruebas propias de marcadores.
Qué cambia para quien sirve modelos con SGLang
El arreglo de fondo quedó en SGLang v0.5.22, publicada el 19 de octubre. Cloudflare recomienda a todo operador que sirva modelos en modo separado que actualice a esa versión o posterior, mida el tamaño real del depósito en cada equipo tras cualquier cambio de pesos, cuantización o paralelismo, y active la liberación diferida de páginas en ambos grupos de tarjetas.
También sumó verificaciones nuevas: una suma de control de la transferencia entre grupos y una canaria de memoria que detecta corrupción posible. La empresa trabaja con RadixArk, responsable de SGLang, en etiquetas por página para que el motor detecte, al leer, que una página no pertenece a esa petición y falle solo esa solicitud. En pruebas internas ese prototipo costó menos del 1 % de rendimiento.
Para una empresa hispana que manda documentos largos a un modelo alojado, la lección práctica es concreta. Conviene preguntar al proveedor cómo separa a cada cliente, dónde publica sus informes de incidentes y qué versión del motor sirve el modelo contratado. Y conviene no enviar en una sola petición un contrato entero o datos personales si basta un extracto depurado.
El fallo de Cloudflare Workers AI y su filtración entre clientes quedaron cerrados en septiembre, pero la divulgación completa llegó casi siete semanas después, coordinada con el investigador y con los responsables del motor. Quien opere SGLang por su cuenta y siga en una versión anterior a la 0.5.22 mantiene abierta, en su propia infraestructura, la misma ruta que Cloudflare tardó 13 días en detectar.
Fuente: Cloudflare
Foto: Cloudflare
Descubre más desde Tecnología Geek
Suscríbete y recibe las últimas entradas en tu correo electrónico.
