A Cloudflare revelou que sua plataforma Workers AI vazou dados entre sessões de clientes no modelo GLM-5.3 entre 27 de agosto e 9 de setembro de 2026, afetando 155 respostas antes de a empresa tirar o modelo do ar e lançar uma correção. O bug, detalhado em um relatório de remediação no blog da Cloudflare, atingiu apenas prompts com mais de 681,280 tokens e foi reportado por meio do programa HackerOne da Cloudflare pelo pesquisador de segurança Gadi Evron, da Knostic.

A Workers AI serve o GLM-5.3 — um modelo de geração de texto da Z.ai construído para fluxos de trabalho de codificação agêntica — por meio do SGLang, um mecanismo de inferência de código aberto, em uma configuração desagregada de prefill/decode. Um pool de GPUs de prefill processa o prompt e constrói o cache KV do modelo, depois transfere esse cache via RDMA usando o Mooncake para um pool separado de GPUs de decode que geram a resposta. O próprio cache KV reside em um pool compartilhado de páginas de memória da GPU de tamanho fixo que não são zeradas entre requisições; a próxima requisição que reivindicar uma página simplesmente a sobrescreve, o que é prática padrão por questões de desempenho, mas coloca todo o ônus de rastrear a propriedade das páginas no mecanismo de inferência.

O próprio relatório da Cloudflare atribui o incidente a duas falhas sobrepostas. Primeiro, uma incompatibilidade de configuração: o GLM-5.3 foi implantado com uma janela de contexto de 1,048,576 tokens, mas o pool de cache KV nas GPUs de prefill da Cloudflare só tinha espaço para 681,280 tokens — uma lacuna que, segundo a empresa, já era conhecida antes do lançamento, mas que se presumiu que o mecanismo lidaria de forma correta, já que os testes pré-lançamento retornaram códigos HTTP de sucesso sem frames de erro. Segundo, um bug na forma como o SGLang lidava com prompts acima do limite no modo desagregado: quando um prompt não cabia no pool, o scheduler deveria rejeitá-lo, mas em vez disso o substituía por um placeholder de um único token e o deixava seguir pelo pipeline normal. O prefill gerou um cache KV para esse placeholder e o transferiu para o nó de decode, que presumiu que a transferência havia sobrescrito integralmente os dados da requisição anterior. Não havia — o nó de decode então gerou uma resposta atendendo a páginas de cache obsoletas que ainda continham prompts e gerações parciais de outros usuários, retornando HTTP 200 com texto coerente em vez do erro esperado.

A linha do tempo do incidente da Cloudflare mostra que a equipe de Product Security reproduziu o vazamento em até 25 minutos após declarar um incidente em 9 de setembro, tornou o modelo privado em cerca de 40 minutos após essa declaração, e o restaurou no mesmo dia após implantar uma configuração corrigida — elevando o pool de KV de prefill para aproximadamente 2.04 milhões de tokens, cerca do dobro do comprimento de contexto — além de um mecanismo corrigido. A empresa afirma não ter encontrado evidências de exploração deliberada; as 155 respostas afetadas eram consistentes em tempo e volume com o uso normal de contexto longo, uma vez excluídos os próprios testes da Cloudflare e as tentativas de reprodução do pesquisador.

O bug subjacente do SGLang já havia sido registrado por outro usuário como issue #30233 em 6 de julho de 2026, algo que, segundo a Cloudflare, a empresa notou ao investigar este incidente. A correção para esse problema chegou na versão v0.5.20 do SGLang, com ajustes adicionais nas versões v0.5.21 e v0.5.22, e a Cloudflare afirma que agora recomenda que todos os operadores do SGLang atualizem para a v0.5.22 ou posterior. A Cloudflare também afirma ter estendido a liberação adiada de páginas de KV para cobrir todo tipo de falha, não apenas abortos, implantado lotes de transferência do Mooncake com limites para que nenhuma chamada de transferência individual ultrapasse um timeout de liberação, e alterado seu balanceador de carga para que a desconexão de um cliente não aborte mais uma requisição no meio da transferência.

O que permanece sem solução é estrutural, não corrigido. A publicação da Cloudflare afirma claramente que verificações de configuração e correções de ciclo de vida "não tornam o mau uso impossível", e que o protótipo de agosto da empresa para marcação de integridade em nível de página — que custou menos de 1% em throughput e latência de cauda nos testes — foi desativado após problemas de confiabilidade e está vinculado a backends de atenção e arquiteturas de modelo específicos, portanto ainda não é uma correção geral. A Cloudflare diz que está trabalhando agora com os mantenedores do SGLang na RadixArk em uma versão de produção dessa verificação de integridade e, separadamente, aplicando métodos de verificação formal para modelar a segurança de seu protocolo de transferência de cache KV baseado em RDMA, um projeto que descreve como em andamento, e não concluído.

Para quem opera caches KV compartilhados entre diferentes clientes, a lição é procedimental: a Cloudflare diz que a lacuna que não percebeu foi validar apenas códigos de resposta HTTP e throughput em contextos longos, não a correção da saída, e sua própria recomendação a outros operadores do SGLang é medir o tamanho do pool de KV em relação ao comprimento do contexto diretamente no log de inicialização do mecanismo, em cada nó de prefill e decode, após qualquer alteração em pesos, quantização ou paralelismo — e não inferir segurança a partir de um código de status aprovado.