Cloudflare e a perda de isolamento no cache KV: o caso do modelo GLM-5.3

Em 26 de outubro de 2026, a Cloudflare divulgou os detalhes de um incidente de segurança. Entre 27 de agosto e 9 de setembro de 2026, o modelo GLM-5.3 do Workers AI devolveu a alguns clientes respostas com dados vindos das solicitações de outros usuários. O incidente afetou 155 respostas, todas geradas a partir de prompts com mais de 681.280 tokens. Segundo a Cloudflare, nenhum outro modelo do Workers AI foi afetado. O vazamento teve duas causas. A primeira foi uma discrepância de configuração entre a janela de contexto do modelo (1.048.576 tokens) e a capacidade do pool de cache KV nas GPUs de prefill (681.280 tokens). A Cloudflare sabia dela antes do lançamento, mas não esperava que causasse problemas. A segunda foi um bug no motor de inferência de código aberto SGLang.

Segundo a reconstrução da empresa, quando um prompt ultrapassava o limite do cache KV, o SGLang em modo desagregado marcava a solicitação como rejeitada e a substituía por um marcador, mas não interrompia o fluxo. As filas de admissão verificavam apenas se a execução tinha terminado, não se a solicitação tinha sido rejeitada. Com isso, o nó de decode podia acessar páginas de memória que ainda guardavam dados de prompts anteriores e enviar ao cliente um código HTTP 200 em vez de um erro. Um problema parecido já tinha sido relatado no repositório do SGLang em 6 de julho de 2026, na issue #30233. Além disso, segundo o Unite.AI, com base no relatório oficial, os testes da Cloudflare antes do lançamento verificavam os códigos de resposta HTTP e o desempenho com contextos longos, mas não a correção da saída final do modelo.

O pesquisador de segurança Gadi Evron, da Knostic, relatou o incidente em 8 de setembro de 2026 pelo HackerOne. Em 9 de setembro (UTC), a Cloudflare declarou o incidente às 13h22, depois de reproduzi-lo a partir de duas contas diferentes. O modelo passou a privado às 14h00 e a causa foi identificada às 14h35. O modelo voltou a ser público às 19h40, depois que o pool de cache KV de prefill foi ampliado para cerca de 2,04 milhões de tokens. Isso é mais ou menos o dobro da janela de contexto, como na configuração do GLM 5.2. A correção do SGLang, que agora descarta as solicitações rejeitadas com o erro original antes de qualquer transferência KV, foi proposta upstream (#38704) e está presente desde o SGLang v0.5.20. A publicação do relatório foi coordenada com os mantenedores do SGLang (RadixArk). A Cloudflare recomenda a quem usa o SGLang atualizar para a v0.5.22 ou posterior e comparar, em cada nó, o tamanho do pool KV com o comprimento de contexto. Ainda assim, várias dúvidas permanecem. No relatório, a Cloudflare afirma não ter encontrado provas de exploração deliberada ("We found no evidence of deliberate exploitation"), mas trata-se de uma avaliação interna que nenhum terceiro verificou. A Cloudflare não informa quantos clientes foram afetados e fala apenas em um número pequeno. Também não detalha que dados ficaram expostos nas 155 respostas, nem esclarece se e como os clientes afetados foram avisados. O relatório de pesquisa de Evron ainda não foi publicado.

Separar prefill e decode em infraestruturas distintas torna viável o custo dos contextos longos, mas desloca a fronteira de segurança para a integridade da memória de GPU compartilhada. Quando a otimização de recursos e os testes de desempenho vêm antes da verificação da saída, basta um estado de erro não detectado para que a eficiência vire uma perda acidental de isolamento. — Olya