A Cloudflare revelou, em 26 de outubro de 2026, uma falha de isolamento entre clientes no modelo GLM-5.3 hospedado no Workers AI. Segundo o relatório oficial da empresa, 155 respostas continham dados de pedidos de outros clientes, entre 27 de agosto e 9 de setembro de 2026. Todas as respostas afetadas foram para prompts com mais de 681.280 tokens.
O problema, classificado aqui como CONFIRMADO por se basear em divulgação oficial, não atingiu prompts comuns. A Cloudflare afirma que nenhum outro modelo do Workers AI foi afetado e que não encontrou evidência de exploração deliberada. A empresa descreve apenas um "pequeno número de clientes" afetados, sem informar quantos foram.
Como duas falhas se somaram
A primeira causa foi uma configuração incompatível: o GLM-5.3 foi lançado com uma janela de contexto de 1.048.576 tokens, mas o pool de cache KV dos GPUs de prefill comportava apenas 681.280 tokens. A Cloudflare diz que já conhecia essa diferença e esperava que o motor retornasse um erro para prompts que não coubessem no pool.
A segunda causa foi um bug no SGLang, o motor de inferência de código aberto usado pela plataforma, no modo desagregado de prefill e decode. Um prompt acima do limite era marcado internamente como rejeitado e substituído por um placeholder de um único token, mas, em vez de interromper a requisição com erro, o sistema seguiu adiante. O nó de decode recebeu o sinal de transferência concluída e gerou a resposta lendo páginas de cache que ainda guardavam dados de pedidos anteriores. O cliente recebia HTTP 200, e não HTTP 400, com uma resposta de aparência coerente.
Linha do tempo e correção
O pesquisador Gadi Evron, da Knostic, relatou o problema em 8 de setembro de 2026, pelo programa HackerOne da Cloudflare. No dia 9, a empresa declarou o incidente, tirou o modelo do ar em até 40 minutos após a declaração e o restaurou no mesmo dia, já com a configuração corrigida e o motor corrigido.
Na correção, o pool de prefill passou a comportar cerca de 2,04 milhões de tokens, aproximadamente o dobro da janela de contexto. A Cloudflare também corrigiu o caminho de rejeição no motor e recomenda que todos os operadores atualizem o SGLang para a versão 0.5.22 ou posterior. A correção principal chegou ao SGLang 0.5.20, com desdobramentos nas versões 0.5.21 e 0.5.22.
Por que isso importa
O caso mostra um risco prático da inferência compartilhada em larga escala: o cache KV é uma fronteira de isolamento entre clientes, e não apenas um detalhe de desempenho. Quando o tamanho do pool e o tamanho da janela de contexto não são verificados juntos, e o caminho de erro não é testado com a saída real do modelo, uma falha pode parecer um sucesso — com código 200 e contagem de tokens plausível.
Para equipes que operam o SGLang por conta própria, a lição direta é verificar o tamanho do pool de KV em relação à janela de contexto em cada mudança de implantação e manter o motor atualizado. Para quem usa APIs hospedadas, o episódio reforça o cuidado com dados sensíveis em prompts muito longos, mesmo quando a resposta parece normal.
Crédito da imagem: diagrama publicado pela Cloudflare em seu relatório oficial sobre a exposição do cache KV no GLM-5.3.
Fontes
- Cloudflare — Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang
- Unite.AI — Cloudflare Says GLM-5.3 Bug Leaked 155 Responses Across Tenant Sessions
- AICoder — Cloudflare discloses a cross-request KV cache leak in GLM-5.3 on Workers AI
Transparência: esta matéria foi produzida com auxílio de inteligência artificial, a partir de apuração em fontes públicas da internet, incluindo o relatório oficial da Cloudflare. Consulte as fontes originais listadas abaixo antes de tomar decisões técnicas.
Muse
