Cloudflare detalha falha que vazou dados entre usuários do modelo GLM-5.3

O que aconteceu

Entre 27 de agosto e 9 de setembro de 2026, o modelo GLM-5.3 (@cf/zai-org/glm-5.3), disponível na Workers AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → da Cloudflare, devolveu para alguns clientes pedaços de respostas que pertenciam a outros usuários. A Cloudflare confirmou, em relatório publicado em 26 de outubro, que 155 respostas foram afetadas nesse período, todas geradas a partir de prompts com mais de 681.280 tokens.

O caso veio à tona em 8 de setembro, quando o pesquisador de segurança Gadi Evron, da empresa Knostic, reportou o problema pelo programa de bug bounty da Cloudflare no HackerOne. A equipe reproduziu o vazamento na manhã seguinte e tirou o modelo do ar 40 minutos depois de declarar incidente. O serviço voltou ainda no mesmo dia, com configuração corrigida e uma versão remendada do motor de inferência SGLang.

Segundo a Cloudflare, o volume e o horário das requisições afetadas são compatíveis com uso legítimo de contexto longo, não com exploração deliberada da falha. Nenhum outro modelo hospedado na Workers AI foi atingido.

Como o vazamento acontecia

GLM-5.3 é um modelo da Z.ai voltado para fluxos de codificação agêntica, rodado pela Cloudflare numa arquitetura de prefill/decode desagregada: um pool de GPUs de prefill processa o prompt e gera o KV cache, que é transferido via RDMA (usando o framework Mooncake) para um pool de GPUs de decode, responsável por gerar a resposta. O KV cache fica numa área de memória compartilhada, organizada em páginas de tamanho fixo reaproveitadas entre requisições sem zeragem: a próxima requisição que recebe uma página simplesmente sobrescreve o que estava lá.

Dois problemas se somaram para causar o vazamento:

1. Configuração incompatível. A Cloudflare publicou o GLM-5.3 com janela de contexto de 1.048.576 tokens, mas o pool de KV cache nas GPUs de prefill só tinha espaço para 681.280 tokens. A equipe sabia da diferença, mas os testes pré-lançamento mostravam códigos HTTP corretos e streaming sem erro mesmo em contextos longos, o que levou o time a acreditar que o motor lidava bem com a diferença.
2. Bug no SGLang. Quando um prompt não cabia no pool, o escalonador deveria rejeitar a requisição. Em vez disso, ele trocava o prompt por um placeholder de um token e deixava a requisição seguir pelo fluxo normal de processamento em lote, sem abortar de fato. Em nó único isso não dava problema, porque o cliente recebia o erro no fim. No modo desagregado que a Cloudflare usa, as filas de admissão de prefill e decode checavam apenas se a requisição estava finished(), e uma rejeição ficava guardada em to_finish, não em finished_reason, então essa checagem continuava retornando falso.

Na prática, o decode reservava páginas de memória para o prompt inteiro, mas o prefill só escrevia uma página (a do placeholder) e avisava "transferência completa". O decode então gerava a resposta lendo todas as páginas reservadas, incluindo as que ainda guardavam dados de requisições anteriores de outros usuários. O cliente recebia HTTP 200, com prompt_tokens batendo com o tamanho do prompt original e texto coerente, só que parcialmente vazado de outra sessão.

Linha do tempo

O que a Cloudflare corrigiu

Na configuração, o pool de KV cache do GLM-5.3 passou a ter cerca de 2,04 milhões de tokens, quase o dobro da janela de contexto de 1.048.576 tokens. Isso elimina o caminho de rejeição para qualquer prompt que caiba na janela anunciada, o que por si só já impede o bug de ser acionado.

No motor, a Cloudflare propôs ao projeto SGLang o patch #38704, que faz uma requisição marcada para rejeição ser encerrada na fila de admissão da desagregação antes de qualquer alocação de memória ou transferência de KV cache. Parte dessa lógica já estava em processo de merge como #36988, para um caminho de falha relacionado, e os mantenedores aceitaram a abordagem da Cloudflare em #38935.

Além disso, a empresa estendeu a liberação adiada de páginas de memória (deferred release) para cobrir também as páginas de origem no prefill, limitou o tamanho dos lotes de transferência via Mooncake e mudou o load balancer para não abortar mais uma requisição no meio da transferência quando o cliente desconecta. Todas essas mudanças já valem para todos os modelos que a Cloudflare roda sobre SGLang, não só o GLM-5.3.

Por que isso importa pra quem roda IA em produção

O caso interessa a qualquer equipe que opera inferência própria com SGLang em modo prefill/decode desagregado, não só a quem usa a Workers AI. A Cloudflare publicou recomendações diretas para esses times:

• Medir o tamanho do pool de KV cache e compará-lo com a janela de contexto, em todo nó de prefill e decode, a cada mudança de pesos, quantização, paralelismo ou fração de memória.
• Atualizar para SGLang v0.5.22 ou posterior, que já inclui os patches #36988 e #38935.
• Rodar com liberação adiada de KV cache ativada nos dois papéis (prefill e decode), padrão desde o PR #41023, e limitar o tamanho dos lotes de transferência via Mooncake.
• Ativar as flags --disaggregation-enable-kv-checksum e --kv-canary quando a arquitetura do modelo suportar, para detectar corrupção de cache.
• Configurar o proxy para não abortar requisições no meio do caminho, deixando-as avançar pelo menos até o primeiro token.

Vale o alerta: nem todo modelo tem suporte às checagens de integridade hoje. A própria Cloudflare cita GLM-5.3, GLM-5.3 Flash e DeepSeek V4 como arquiteturas ainda não cobertas pelo checksum de KV cache, o que significa que times rodando esses modelos seguem sem uma rede de segurança automática contra esse tipo de corrupção.

O que ainda está em aberto

A Cloudflare é direta ao afirmar que as correções de configuração e de ciclo de vida de memória reduzem a chance desse tipo de bug, mas não o eliminam por completo. O relatório enquadra o incidente como parte de uma classe maior de bugs de memória em KV cache que a empresa vem endereçando há meses, incluindo corrida entre nós (quando um nó libera uma página enquanto outro ainda escreve nela) e problemas de tempo de vida de página dentro do mesmo nó.

Para esses casos, o plano de longo prazo passa por checagens de integridade a cada passo de geração, não só na transferência entre prefill e decode, trabalho que a Cloudflare descreve como ainda em andamento com os mantenedores do SGLang.

Fonte: Hacker News