Como uma falha de configuração na Cloudflare expôs dados entre clientes de um modelo de IA

A resposta ao incidente

A equipe reproduziu o problema na manhã seguinte ao relato, usando duas contas independentes, e tirou o modelo do ar em até 40 minutos após declarar o incidente. Durante esse período, as requisições passaram a receber erro e a página de status foi atualizada.

No mesmo dia, a Cloudflare implantou uma configuração corrigida e uma versão ajustada do motor de inferência, validou as mudanças com o script de reprodução do pesquisador e com testes próprios, e restabeleceu o serviço. O relatório foi divulgado de forma coordenada com o projeto SGLang, o motor de código aberto usado pela empresa.

Duas falhas que se somaram

A primeira falha foi de configuração. O GLM 5.3 foi lançado com uma janela de contexto de 1.048.576 tokens, mas a área de memória das GPUs responsável pelo cache do processamento inicial comportava apenas 681.280 tokens. A empresa sabia dessa diferença antes do lançamento, mas esperava que o motor retornasse um erro para prompts que não coubessem. Como os testes com contextos longos devolviam respostas bem-sucedidas, o descompasso não foi tratado como risco.

A segunda falha estava no próprio SGLang, no modo em que o processamento do prompt e a geração da resposta ocorrem em grupos separados de GPUs. Um prompt grande demais era marcado internamente como rejeitado e trocado por um marcador de um único token, mas, em vez de ser cancelado com uma mensagem de erro, seguia adiante. A etapa de geração recebia um aviso de transferência concluída e passava a trabalhar sobre páginas de memória que ainda guardavam dados de pedidos anteriores.

Isso só era possível porque as páginas de memória não são zeradas entre pedidos, prática comum em motores de inferência por motivos de desempenho. Cabe ao software controlar a quem cada página pertence. A empresa reconhece ainda uma lacuna nos testes: verificou apenas códigos de resposta e desempenho, sem conferir se o texto gerado fazia sentido.

Correções e trabalho com o SGLang

A Cloudflare ajustou a configuração do GLM 5.3 para espelhar a do GLM 5.2, o que liberou memória suficiente para que o cache comporte cerca de 2,04 milhões de tokens, aproximadamente o dobro da janela de contexto. Assim, qualquer prompt válido passa a caber na memória. Por considerar essa proteção frágil diante de futuras mudanças, a empresa também alterou o motor para que pedidos rejeitados sejam encerrados com o erro original antes de qualquer transferência de dados.

Segundo a Cloudflare, esse tipo de bug já havia sido relatado ao SGLang por outro usuário em julho, e a empresa vinha apontando problemas da mesma família há meses. Em 10 de setembro, houve reunião com os mantenedores na RadixArk para definir correções. Entre as mudanças incorporadas estão a rejeição antecipada desses pedidos e uma verificação opcional da integridade dos dados transferidos entre as etapas. A recomendação aos demais operadores é atualizar o SGLang para a versão 0.5.22 ou posterior. A Cloudflare aplicou as correções a todos os modelos que serve com o SGLang e passou a exigi-las em novas implantações.

O que isso significa para empresas

Para quem consome modelos de IA por meio de provedores, o episódio mostra que o vazamento de dados não depende apenas de ataques: pode surgir de detalhes de infraestrutura invisíveis ao cliente. Vale considerar quais informações são enviadas em prompts, sobretudo em pedidos muito longos com documentos internos, e acompanhar os comunicados de segurança dos fornecedores.

Para equipes que operam modelos próprios, a lição é direta. Testar se o sistema responde não basta; é preciso verificar se a resposta está correta e se limites de configuração, como memória disponível e janela de contexto, estão de fato alinhados. Manter dependências de código aberto atualizadas e ter um canal ativo para relatos de pesquisadores também fez diferença na rapidez com que o problema foi contido.