A Cloudflare publicou um relatório detalhado de incidentes descrevendo como um bug de manipulação de cache em sua plataforma de IA sem servidor fez com que pelo menos 155 usuários de uma implantação do modelo GLM-5.3 recebessem respostas contendo fragmentos de prompts e resultados de outros clientes. O relatório, publicado em 26 de outubro como uma divulgação coordenada junto com o projeto de mecanismo de inferência de código aberto SGLang, oferece uma rara visão pública do encanamento do serviço LLM multilocatário – e um aviso sobre as suposições de segurança da memória GPU.
Como o vazamento foi encontrado Para mais contexto sobre esta história, confira nossa notícias de IA.
De acordo com a Cloudflare, o pesquisador de segurança Gadi Evron, da Knostic, alertou a empresa em 8 de setembro de 2026, por meio de seu programa de recompensas por bugs HackerOne. Evron relatou que prompts muito longos enviados ao modelo GLM-5.3 na plataforma Workers AI da Cloudflare às vezes retornavam texto que pertencia a sessões de outros usuários. A Cloudflare reproduziu o problema na manhã seguinte e desativou o modelo no mesmo dia, restaurando-o em 9 de setembro após implantar as correções.
O modelo afetado foi @cf/zai-org/glm-5.3 — o modelo de codificação de agente da Z.ai que a Cloudflare atende por meio do Workers AI, a plataforma de inferência sem servidor da empresa. A Cloudflare confirmou que nenhum outro modelo hospedado na plataforma foi afetado.
O que realmente aconteceu
O incidente remonta a dois problemas sobrepostos, um operacional e outro no próprio motor.
Primeiro, a configuração incorreta. A Cloudflare implantou o GLM-5.3 com uma janela de contexto de 1.048.576 tokens, mas o pool de cache de valor-chave (KV) em suas GPUs pré-preenchidas só tinha espaço para 681.280 tokens. A empresa reconheceu que estava ciente dessa incompatibilidade antes do lançamento e esperava que o mecanismo de inferência rejeitasse solicitações de comprimento excessivo com segurança.
Em segundo lugar, o bug do motor. No modo de pré-preenchimento/decodificação desagregado – a arquitetura que o Workers AI usa, na qual um pool de GPUs processa o prompt e entrega o cache KV resultante para um pool separado de GPUs que geram a resposta – o SGLang tratou a solicitação de comprimento excessivo incorretamente. Um prompt que não cabia no pool foi marcado internamente como rejeitado e substituído por um espaço reservado de um token. Mas, em vez de abortar a solicitação e retornar um erro do cliente, o estágio de pré-preenchimento gerou cache KV para o prompt de espaço reservado e o transferiu para o nó de decodificação, que então produziu uma resposta que misturou dados restantes de solicitações anteriores compartilhando as mesmas páginas de memória.
O resultado: entre 27 de agosto e 9 de setembro, um pequeno número de clientes que utilizaram o modelo receberam respostas contendo dados de solicitações de outros clientes feitas pouco antes das suas. No total, 155 respostas foram afetadas – todas, descobriu a Cloudflare, para solicitações com mais de 681.280 tokens.
Nenhuma evidência de exploração deliberada
A Cloudflare afirmou que, depois de excluir seus próprios testes e as solicitações de validação do pesquisador, as solicitações afetadas eram consistentes em termos de tempo e volume com o uso normal de longo contexto, e a empresa não encontrou nenhuma evidência de que alguém explorou deliberadamente o bug. Como todas as solicitações afetadas excediam a capacidade do pool subdimensionado, a janela de exposição era estreitamente limitada – uma fresta de esperança que decorre da própria configuração incorreta que causou o problema.
A solução: pools maiores e um caminho de falha mais seguro
A correção funcionou em ambas as camadas da falha. A Cloudflare reconfigurou sua implantação do GLM-5.3 para corresponder à configuração do GLM-5.2, liberando memória de GPU suficiente para que o pool KV pré-preenchido agora contenha cerca de 2,04 milhões de tokens – aproximadamente o dobro do comprimento de contexto de 1.048.576 tokens do modelo. Um prompt que se ajusta à janela de contexto agora sempre se ajusta ao pool.
Mas a empresa também enfatizou que depender apenas do dimensionamento do pool é frágil: mudanças na quantização, paralelismo de tensores, tamanhos de gráficos CUDA ou uma versão futura do modelo podem alterar silenciosamente o tamanho do pool. Portanto, ele também corrigiu o próprio caminho de rejeição do SGLang, garantindo que uma solicitação rejeitada fosse abortada de forma limpa, em vez de gerar e transferir cache para um espaço reservado. Ambas as alterações foram validadas com base no script de reprodução do pesquisador e nos próprios testes de marcadores canários da Cloudflare antes de o modelo ser restaurado, e as correções foram contribuídas upstream para os mantenedores do SGLang.
Por que a memória GPU compartilhada é uma questão de segurança
O relatório explica uma prática que surpreenderá muitos desenvolvedores de aplicativos: os mecanismos de inferência geralmente não zeram as páginas de cache KV entre as solicitações, porque a próxima solicitação simplesmente as sobrescreve. Esta é uma compensação deliberada de desempenho, comum em mecanismos de inferência, mas, como mostra esse incidente, qualquer caminho que permita gerar uma resposta antes que essas páginas sejam totalmente substituídas transforma uma otimização de desempenho em um vetor de vazamento de dados.
A divulgação chegou à comunidade de desenvolvedores: a história alcançou 123 pontos no Hacker News em poucas horas, com a discussão focada em como o modo de falha – uma solicitação que deveria ter falhado ruidosamente em vez de prosseguir silenciosamente no estado corrompido – reflete as lições clássicas da engenharia de sistemas distribuídos.
Uma lição mais ampla para infraestrutura de IA
O incidente lembra que o perímetro de segurança para aplicações de IA agora se estende profundamente à infraestrutura de inferência. O serviço de modelo multilocatário concentra muitos dados de clientes por meio de aceleradores compartilhados, pools de cache compartilhados e arquiteturas cada vez mais exóticas, como pré-preenchimento desagregado e acesso remoto direto à memória. Uma incompatibilidade sutil entre a janela de contexto anunciada de um modelo e a capacidade física provisionada para atendê-lo foi suficiente para quebrar o isolamento do locatário.
Para empresas que desenvolvem plataformas de IA sem servidor, a conclusão do relatório da Cloudflare é dupla: os bugs de isolamento de locatários no serviço LLM são reais e já aconteceram na produção, e o tempo de resposta dos fornecedores – menos de 24 horas desde o relatório até a desativação, um dia para correção e restauração – é o padrão de diligência para exigir de qualquer provedor que lide com solicitações confidenciais.
---
Fique à Frente da IAAs últimas notícias, análises e avanços em inteligência artificial — tudo em um só lugar.
Ler mais notícias de IA →
