Cloudflare corrige una fuga de caché KV entre solicitudes en su modelo GLM-5.3

Cloudflare publicó el 26 de octubre de 2026 un informe técnico detallado sobre una fuga de caché KV entre solicitudes que afectó a GLM-5.3 (@cf/zai-org/glm-5.3), uno de los modelos disponibles en Workers AI. Durante casi dos semanas, algunas solicitudes de contexto muy largo pudieron recibir fragmentos de texto procedentes de sesiones de otros clientes. La empresa detalla la cronología completa y las correcciones aplicadas.

#Un desajuste de configuración invisible para las pruebas

GLM-5.3 se desplegó el 27 de agosto de 2026 con una ventana de contexto anunciada de 1.048.576 tokens, pero el pool de caché KV reservado al prerrelleno solo cubría 681.280 tokens. Cloudflare sabía que las dos cifras no coincidían antes del lanzamiento, pero sus pruebas internas devolvían respuestas HTTP 200 válidas, lo que ocultó el problema.

#Un error de SGLang que convierte un rechazo en fuga

El motor de inferencia SGLang, usado entre bastidores, marca normalmente una solicitud demasiado larga como rechazada y le sustituye un token de relleno. En modo desagregado, la cola de admisión solo comprobaba si la solicitud había terminado, no si había sido rechazada. El token de relleno era por tanto aceptado: el prerrelleno transfería una sola página de caché, mientras que la decodificación reservaba ocho, siete de las cuales aún contenían datos de solicitudes anteriores.

El servidor devolvía un código HTTP 200, como si fuera una respuesta normal, cuando la solicitud debería haberse rechazado con un código 400.

#Cronología del incidente

En total, Cloudflare contabiliza 155 respuestas afectadas, sin evidencia de explotación deliberada más allá de sus propias pruebas y las del investigador. El pool de caché se ha ampliado desde entonces hasta cerca de 2,04 millones de tokens, el doble de la ventana de contexto anunciada, para que cualquier solicitud válida quepa. Los 25 minutos entre la reproducción y la declaración del incidente deben mucho a una supervisión bien instrumentada y un triaje de alertas rodado, dos reflejos válidos para cualquier infraestructura compartida entre clientes.

#Qué deben revisar los operadores de SGLang en modo desagregado

Más allá de Workers AI, la alerta concierne a cualquier equipo que opere SGLang en modo desagregado para su propio servicio de inferencia. Cloudflare recomienda comparar el tamaño del pool KV con la ventana de contexto anunciada, al arrancar y tras cada cambio de configuración. El mismo reflejo ya recomendado tras el fallo RCE del decodificador Brotli de Node.js a principios de octubre: verificar la configuración real en producción, no solo su documentación.

# Comparar el pool KV declarado al arrancar con la ventana de contexto del modelo
grep -i "kv_pool\|context_length" sglang_server.log | tail -n 20

# Actualizar a una versión corregida (incluye la corrección de admisión)
pip install "sglang>=0.5.22"

# Activar las protecciones recomendadas en modo desagregado
python -m sglang.launch_server \
  --disaggregation-mode decode \
  --disaggregation-enable-kv-checksum \
  --kv-canary

#Lo que hay que recordar

El incidente no proviene de una inyección ni de una elusión activa, sino del encuentro entre una configuración mal calibrada y un error de admisión que permaneció silencioso durante meses en SGLang, un recordatorio de que la infraestructura de inferencia compartida es ya una capa propia de las arquitecturas agénticas. La corrección está en producción desde el 9 de septiembre de 2026; el informe del 26 de octubre sirve sobre todo para alertar a los operadores independientes de SGLang que no hayan seguido las correcciones en origen.

Para saber más: el informe completo de Cloudflare está disponible en blog.cloudflare.com.