Cloudflare y la pérdida de aislamiento en la caché KV: el caso del modelo GLM-5.3

El 26 de octubre de 2026, Cloudflare publicó los detalles de un incidente de seguridad. Entre el 27 de agosto y el 9 de septiembre de 2026, el modelo GLM-5.3 de Workers AI devolvió a algunos clientes respuestas con datos procedentes de las solicitudes de otros usuarios. El incidente afectó a 155 respuestas, todas generadas a partir de prompts de más de 681.280 tokens. Según Cloudflare, ningún otro modelo de Workers AI se vio afectado. La fuga tuvo dos causas. La primera fue un desajuste de configuración entre la ventana de contexto del modelo (1.048.576 tokens) y la capacidad del pool de caché KV en las GPU de prefill (681.280 tokens). Cloudflare lo conocía antes del lanzamiento, pero no esperaba que causara problemas. La segunda fue un error en el motor de inferencia de código abierto SGLang.

Según la reconstrucción de la empresa, cuando un prompt superaba el límite de la caché KV, SGLang en modo desagregado marcaba la solicitud como rechazada y la sustituía por un marcador de posición, pero no detenía el flujo. Las colas de admisión solo comprobaban si la ejecución había terminado, no si la solicitud había sido rechazada. Así, el nodo de decode podía acceder a páginas de memoria que aún conservaban datos de prompts anteriores y enviar al cliente un código HTTP 200 en lugar de un error. Ya el 6 de julio de 2026 se había notificado un problema similar en el repositorio de SGLang, con la issue #30233. Además, según recoge Unite.AI a partir del informe oficial, las pruebas previas al lanzamiento de Cloudflare comprobaban los códigos de respuesta HTTP y el rendimiento con contextos largos, pero no la corrección de la salida final del modelo.

El investigador de seguridad Gadi Evron, de Knostic, notificó el incidente el 8 de septiembre de 2026 a través de HackerOne. El 9 de septiembre (UTC), Cloudflare declaró el incidente a las 13:22, tras reproducirlo desde dos cuentas distintas. El modelo pasó a privado a las 14:00 y la causa se identificó a las 14:35. El modelo volvió a ser público a las 19:40, después de ampliar el pool de caché KV de prefill a unos 2,04 millones de tokens. Es aproximadamente el doble de la ventana de contexto, como en la configuración de GLM 5.2. La corrección de SGLang, que ahora descarta las solicitudes rechazadas con su error original antes de cualquier transferencia KV, se propuso upstream (#38704) y está incluida desde SGLang v0.5.20. La publicación del informe se coordinó con los mantenedores de SGLang (RadixArk). Cloudflare recomienda a quien use SGLang actualizar a la v0.5.22 o posterior y comparar en cada nodo el tamaño del pool KV con la longitud de contexto. Aun así, quedan varias incógnitas. En el informe, Cloudflare afirma no haber encontrado pruebas de una explotación deliberada ("We found no evidence of deliberate exploitation"), pero es una valoración interna que ningún tercero ha verificado. Cloudflare no dice cuántos clientes se vieron afectados, solo habla de un número pequeño. Tampoco precisa qué datos quedaron expuestos en las 155 respuestas ni aclara si se informó a los clientes afectados, ni de qué manera. El informe de investigación de Evron aún no se ha publicado.

Separar prefill y decode en infraestructuras distintas hace asumible el coste de los contextos largos, pero desplaza la frontera de seguridad a la integridad de la memoria GPU compartida. Cuando la optimización de recursos y las pruebas de rendimiento van antes que la verificación de la salida, basta un estado de error no detectado para que la eficiencia se convierta en una pérdida accidental de aislamiento. — Olya