Imagine fazer uma pergunta a uma IA e receber, junto com a resposta, pedaços da conversa de outra pessoa. Foi o que aconteceu com alguns clientes do Workers AI, o serviço de IA da Cloudflare, entre agosto e setembro de 2026.
A falha na Cloudflare afetou só o modelo GLM-5.3 e 155 respostas no total. Mesmo pequeno, o caso virou referência porque mostra um tipo de risco pouco conhecido de quem usa IA na nuvem: o vazamento de dados pela memória compartilhada das GPUs.
A empresa publicou um relatório detalhado em conjunto com os mantenedores do SGLang, o software de código aberto que roda o modelo. Veja o que aconteceu, como foi corrigido e o que isso ensina.
O que aconteceu, em resumo
Segundo a Cloudflare, o problema existia desde o lançamento do GLM-5.3 no Workers AI, em 27 de agosto de 2026. Em 8 de setembro, o pesquisador de segurança Gadi Evron, da Knostic, relatou o caso pelo programa de recompensas da empresa no HackerOne.
A Cloudflare reproduziu a falha na manhã seguinte e tirou o modelo do ar em até 40 minutos depois de declarar o incidente. No mesmo dia, 9 de setembro, o serviço voltou com a configuração corrigida e uma versão ajustada do software.
| Item | Detalhe informado pela Cloudflare |
|---|---|
| Modelo afetado | GLM-5.3, da Z.ai (só ele) |
| Período | 27 de agosto a 9 de setembro de 2026 |
| Respostas afetadas | 155, todas com prompts acima de 681.280 tokens |
| Exploração proposital | Nenhuma evidência encontrada |
| Correção no SGLang | Versão 0.5.20, com ajustes nas 0.5.21 e 0.5.22 |
A empresa afirma que, tirando os próprios testes e os do pesquisador, os pedidos afetados batem com uso normal de contexto longo, e não com alguém explorando a falha de propósito.
O que é o cache KV, em linguagem simples
Quando um modelo de linguagem lê o seu prompt, ele gera uma espécie de rascunho interno com o que já entendeu do texto. Esse rascunho é o cache KV, e ele fica guardado na memória da GPU enquanto a resposta é escrita.
Para ganhar velocidade, essa memória é dividida em páginas de tamanho fixo e compartilhada entre vários pedidos. Quando um pedido termina, as páginas não são apagadas: o próximo simplesmente escreve por cima. É uma prática comum nos motores de inferência, mas exige controle rigoroso de quem é dono de cada página.
Se esse controle falhar, um pedido pode acabar lendo páginas que ainda guardam o rascunho de outro usuário. Foi exatamente isso que aconteceu aqui.
As duas falhas que se somaram
O relatório aponta dois problemas que, juntos, causaram o vazamento:
- Configuração: o GLM-5.3 foi lançado anunciando uma janela de contexto de 1.048.576 tokens, mas a memória reservada para o cache nas GPUs que processam o prompt só cabia 681.280 tokens. A equipe sabia da diferença, mas esperava que o sistema devolvesse erro para prompts grandes demais.
- Bug no SGLang: no modo em que o processamento do prompt e a geração da resposta ficam em máquinas separadas, o prompt longo demais era rejeitado e trocado por um marcador de um único token. Só que o pedido seguia adiante como se estivesse tudo certo.
A máquina que gera a resposta reservava espaço para o prompt inteiro, mas recebia só uma página escrita. As outras páginas ainda tinham dados de pedidos anteriores. O cliente recebia um código de sucesso, e não de erro, com uma resposta coerente que misturava conteúdo alheio.
A Cloudflare admite uma lacuna nos testes: antes do lançamento, só foram conferidos os códigos de resposta e o desempenho, sem validar se o texto gerado fazia sentido.
Como a falha foi corrigida
A correção veio em duas frentes. Na configuração, a Cloudflare ajustou o GLM-5.3 para liberar memória, e o espaço do cache passou a comportar cerca de 2,04 milhões de tokens, o dobro da janela de contexto. Assim, qualquer prompt válido cabe na memória.
No software, a empresa fez o SGLang descartar pedidos rejeitados antes de qualquer transferência de dados, devolvendo o erro original ao cliente. A proposta foi enviada ao projeto e incorporada nas versões seguintes, junto com uma checagem de integridade dos dados transferidos entre as máquinas.
A Cloudflare também conta que já vinha trabalhando com o time do SGLang em problemas parecidos de memória desde a versão 0.5.10, e se reuniu com os mantenedores no dia seguinte ao incidente para acelerar as correções.
O que isso muda para quem usa IA
Para quem usa o Workers AI, a empresa garante que nenhum outro modelo foi afetado e que as correções foram aplicadas em todos os modelos servidos com SGLang. Para o resto do mercado, o recado é mais amplo.
Quem roda o SGLang no modo separado de processamento e geração deve atualizar para a versão 0.5.22 ou mais recente, segundo a recomendação da própria Cloudflare. E deve conferir se a memória reservada ao cache é maior que a janela de contexto anunciada.
Para empresas brasileiras que enviam dados de clientes a modelos de IA, o caso reforça um ponto da LGPD: avaliar fornecedores também pelo histórico de segurança e evitar mandar dados pessoais desnecessários nos prompts.
Perguntas frequentes
Meus dados podem ter vazado?
Só se você usou o modelo GLM-5.3 no Workers AI entre 27 de agosto e 9 de setembro de 2026, com prompts acima de 681.280 tokens. Fora isso, a Cloudflare diz que nenhum outro modelo foi afetado.
O que é o SGLang?
É um motor de inferência de código aberto, um software que roda modelos de linguagem em GPUs de forma eficiente. A Cloudflare o usa para servir vários modelos no Workers AI.
Quem descobriu a falha?
O pesquisador Gadi Evron, da empresa Knostic, que relatou o problema pelo programa de recompensas da Cloudflare no HackerOne.
O ChatGPT ou o Claude foram afetados?
Não. O incidente envolveu apenas o modelo GLM-5.3 rodando na infraestrutura da Cloudflare.
Conclusão
A falha na Cloudflare mostra que velocidade e compartilhamento de memória têm um preço: qualquer erro de controle pode expor dados entre usuários. A resposta rápida e o relatório transparente ajudam o ecossistema inteiro a evitar o mesmo problema.
Quer ver outros casos de segurança envolvendo ferramentas de IA? Leia sobre o LiteLLM comprometido no PyPI e as 5 falhas de segurança que a IA deixa no código. O relatório original está no blog da Cloudflare.