Cloudflare detalha vazamento de cache KV entre requisições no modelo GLM-5.3 do Workers AI e correção no…

O que aconteceu

De acordo com a Cloudflare, o pesquisador Gadi Evron, da Knostic, enviou em 8 de setembro de 2026, pelo programa de HackerOne da empresa, um relatório sobre um problema de isolamento entre clientes no modelo @cf/zai-org/glm-5.3 do Workers AI. Segundo a empresa, a exposição existia desde o lançamento do modelo, em 27 de agosto de 2026.

A Cloudflare afirma que, entre 27 de agosto e 9 de setembro, um pequeno número de clientes recebeu respostas com dados de requisições feitas por outros clientes ao mesmo modelo pouco antes. No total, foram 155 respostas afetadas, todas para prompts com mais de 681.280 tokens. Depois de excluir testes próprios e do pesquisador, a empresa diz que os casos são compatíveis em tempo e volume com uso normal de contexto longo e que não encontrou evidência de exploração deliberada. A Cloudflare também afirma ter confirmado que nenhum outro modelo hospedado no Workers AI foi afetado.

A empresa reproduziu o problema na manhã de 9 de setembro, declarou incidente de segurança e, segundo o relato, tirou o modelo do ar em até 40 minutos após essa declaração. Em seguida, aplicou uma configuração corrigida e um patch no motor de inferência, restaurando o serviço no mesmo dia. A publicação foi feita em coordenação com um texto do projeto SGLang, o motor open source usado pela Cloudflare.

Segundo a Cloudflare, o incidente resultou de dois problemas sobrepostos: uma configuração incorreta e um bug do SGLang.

Principais novidades

• Foram 155 respostas afetadas, todas para prompts acima de 681.280 tokens, segundo a Cloudflare.
• O modelo foi colocado como privado em 9 de setembro (requisições retornavam HTTP 400) e restaurado ao público no mesmo dia, às 19:40 UTC.
• A causa combinou um pool de KV cache menor que a janela de contexto com um bug no tratamento de requisições rejeitadas no modo disaggregated do SGLang.
• A Cloudflare ampliou o pool de prefill para cerca de 2,04 milhões de tokens, aproximadamente o dobro da janela de contexto de 1.048.576 tokens.
• A empresa criou um patch para encerrar requisições rejeitadas antes de qualquer transferência de KV e propôs a mudança ao projeto upstream como #38704.
• A Cloudflare recomenda que operadores atualizem o SGLang para a v0.5.22 ou posterior.
• Segundo a empresa, apenas o GLM-5.3 foi afetado, e as correções e verificações foram aplicadas a todos os modelos servidos com SGLang.

Contexto técnico

O GLM é um modelo de geração de texto da Z.ai voltado a fluxos de programação com agentes. No Workers AI, o GLM 5.3 roda com SGLang em configuração disaggregated: GPUs de prefill processam o prompt e geram o KV cache, que é enviado via RDMA, com Mooncake, a GPUs de decode que geram a resposta.

O KV cache fica em um pool compartilhado de páginas de tamanho fixo. Segundo a Cloudflare, as páginas não são zeradas entre requisições; a próxima requisição que as recebe simplesmente as sobrescreve, o que exige que o motor controle a posse de cada página. O tamanho do pool não é um valor de configuração: o SGLang o calcula na inicialização com base na memória de GPU restante após carregar os pesos, e o contexto anunciado do modelo é um valor separado.

Problema 1: configuração. Nos nós de prefill do GLM 5.3, o pool ficou com 681.280 tokens, enquanto o contexto era de 1.048.576. A Cloudflare diz que conhecia a diferença antes do lançamento, mas viu códigos HTTP de sucesso e respostas em streaming sem erros nos testes, e presumiu que o motor lidaria com a situação. Segundo a empresa, os testes validaram só códigos de resposta e desempenho, não a coerência da saída.

Problema 2: bug no SGLang. Quando o prompt excedia o pool, o scheduler o rejeitava por meio de Req.set_finish_with_abort, que registrava o erro e trocava o prompt por um placeholder de um token. Em implantação de nó único, isso resultava em erro ao cliente. No modo disaggregated, as filas de admissão checavam req.finished(), que retornava False para requisições rejeitadas, pois a rejeição ficava em to_finish e não em finished_reason. Assim, o prefill processava o placeholder, enviava uma página de KV e sinalizava transferência concluída. O decode, que havia reservado, no exemplo do texto, 8 páginas, lia todas elas, e as páginas P1 a P7 ainda continham dados de requisições anteriores. O cliente recebia HTTP 200 em vez de HTTP 400, com prompt_tokens compatível com o prompt longo e resposta coerente.

Segundo a Cloudflare, o bug havia sido reportado por outro usuário ao SGLang como issue #30233 em 6 de julho de 2026. O patch saiu na v0.5.20, com ajustes nas v0.5.21 e v0.5.22.

Correções imediatas. A empresa alinhou a configuração do GLM 5.3 à do GLM 5.2, de modo que um prompt que cabe na janela de contexto sempre caiba no pool. Também corrigiu o caminho de rejeição: uma requisição com rejeição pendente é encerrada na fila de admissão da disaggregation, com o erro original, antes de bootstrap, alocação ou transferência de KV. A proposta upstream (#38704) também fazia o decode verificar se o número de tokens transferidos corresponde ao reservado. A correção já estava no main do SGLang em #36988, mesclada em 6 de setembro para um caminho de falha relacionado, e os mantenedores mesclaram #38935, que rejeita essas requisições mais cedo.

Endurecimento contínuo. A Cloudflare descreve uma classe de bugs de segurança de memória no KV cache, em que uma página é liberada, reutilizada ou lida enquanto outra parte ainda tem direito a ela, seja dentro de um nó, seja em corridas entre nós quando uma requisição é abortada durante a escrita via RDMA. Desde o incidente, a empresa diz ter estendido a liberação adiada para cobrir também as páginas de origem do prefill e todos os tipos de falha (proposta #38961, substituída por #40645, #41402 e #41404), adotado lotes limitados de transferência do Mooncake (#32758), alterado o balanceador de carga para que a desconexão do cliente não aborte requisição no meio da transferência e adicionado verificações a toda mudança de implantação disaggregated: tamanho do pool de KV frente ao contexto, liberação adiada nos dois papéis, limites de lote dentro do timeout de liberação e patches obrigatórios aplicados.

Impacto

Para clientes do Workers AI que usaram o @cf/zai-org/glm-5.3 com prompts muito longos entre 27 de agosto e 9 de setembro, o incidente significa que parte das respostas pode ter incluído dados de terceiros. A Cloudflare diz que o problema afetou apenas prompts acima de 681.280 tokens e que o modelo já foi restaurado com a correção.

Para quem opera SGLang por conta própria, especialmente em modo disaggregated de prefill/decode, a empresa recomenda atualizar para a v0.5.22 ou posterior. O relato também ressalta a necessidade de comparar o tamanho do pool de KV com a janela de contexto configurada e de validar a saída do modelo, e não apenas códigos HTTP, em testes de contexto longo.