Cloudflare afirma que uma falha no GLM-5.3 vazou 155 respostas entre sessões de clientes

Em 26 de outubro de 2026, a Cloudflare publicou um relatório de incidente que revelou uma exposição do cache KV entre solicitações no modelo GLM-5.3 de sua plataforma Workers AI. Como resultado, 155 respostas a prompts muito longos continham dados de sessões de outros clientes.

O pesquisador de segurança Gadi Evron, da Knostic, comunicou à Cloudflare o problema de isolamento entre clientes em 8 de setembro de 2026, por meio do programa HackerOne da empresa. A exposição afetou o modelo, disponibilizado como @cf/zai-org/glm-5.3, a partir de 27 de agosto de 2026, dia em que o GLM 5.3 foi lançado no Workers AI. A Cloudflare corrigiu o problema e restaurou o modelo em 9 de setembro de 2026, e afirmou ter confirmado que nenhum outro modelo hospedado no Workers AI foi afetado.

Todas as 155 respostas afetadas foram geradas para prompts com mais de 681.280 tokens. A Cloudflare afirmou que, depois de excluir os próprios testes e as solicitações do pesquisador, as solicitações identificadas correspondiam ao uso normal de contexto longo em termos de horário e volume, e não a uma exploração repetida da falha, e que não encontrou indícios de exploração deliberada.

Os dois problemas por trás da exposição

O GLM é um modelo de geração de texto da Z.ai, desenvolvido para fluxos de trabalho de programação com agentes, e um entre os muitos modelos disponíveis no Workers AI. A Cloudflare executa o GLM 5.3 com o SGLang, um mecanismo de inferência de código aberto, em uma configuração desagregada: as GPUs de prefill processam o prompt e geram seu cache KV; em seguida, transferem esse cache por acesso remoto direto à memória (RDMA), via Mooncake, para as GPUs de decode, que geram a resposta. O cache KV é um conjunto compartilhado de páginas de tamanho fixo; as páginas não são zeradas entre solicitações, então cabe ao mecanismo controlar a propriedade de cada página.

O relatório atribui a exposição a dois problemas. O primeiro foi uma configuração incorreta: a Cloudflare implantou o GLM 5.3 com uma janela de contexto de 1.048.576 tokens, mas o conjunto de cache KV nas GPUs de prefill comportava apenas 681.280 tokens. A Cloudflare afirmou que sabia da discrepância antes do lançamento, mas esperava que o mecanismo retornasse um erro para qualquer prompt que não pudesse processar. Como seus testes de contexto longo retornaram respostas bem-sucedidas, a empresa não acreditou que a discrepância fosse um problema. A empresa afirmou que seus testes validavam os códigos de resposta HTTP e o desempenho do mecanismo com contextos longos, mas não a saída nem a coerência do modelo, e que agora verifica diretamente o tamanho do conjunto de KV em relação ao comprimento do contexto antes de liberar qualquer alteração em uma implantação desagregada.

O segundo problema foi uma falha no SGLang ao lidar com solicitações acima do limite no modo desagregado de prefill e decode. Um prompt que não cabia no conjunto era marcado internamente como rejeitado e substituído por um espaço reservado de um token, mas o prefill ainda gerava um cache KV para esse espaço reservado e sinalizava que a transferência havia sido concluída. Em seguida, o nó de decode gerava uma resposta calculando a atenção sobre páginas obsoletas do cache que ainda continham dados de solicitações anteriores, e o cliente recebia uma resposta HTTP 200 em vez de HTTP 400.

A equipe do SGLang afirma em sua própria publicação conjunta que o caminho de rejeição em nó único retornava um erro; portanto, o problema ocorria apenas no serviço desagregado. Outro usuário havia comunicado a falha ao SGLang como o problema #30233 em 6 de julho de 2026, e a Cloudflare afirmou que tomou conhecimento dela durante a investigação.

Resposta ao incidente e correção

A Cloudflare começou a verificar o relatório às 08h00 UTC de 9 de setembro de 2026 e declarou um incidente de segurança às 13h22, depois que sua equipe de Segurança de Produtos reproduziu o vazamento usando duas contas independentes em 25 minutos. A empresa tornou o GLM 5.3 privado às 14h00, identificou a causa raiz às 14h35, atualizou todos os nós de prefill para a configuração corrigida até as 14h52, recompilou toda a implantação com um patch do mecanismo desenvolvido pela Cloudflare até as 19h04 e restabeleceu o acesso público ao modelo às 19h40. A página de status da Cloudflare registrou que o incidente no Workers AI começou às 10h25 EDT de 9 de setembro de 2026, foi identificado às 11h02 EDT e resolvido às 16h09 EDT.

A correção da configuração seguiu a configuração do GLM 5.2 e liberou memória suficiente nas GPUs para que o conjunto de cache KV de prefill agora comporte cerca de 2,04 milhões de tokens, aproximadamente o dobro do comprimento da janela de contexto, de 1.048.576 tokens. Assim, um prompt que caiba na janela de contexto sempre caberá no conjunto. O patch do mecanismo encerra uma solicitação com rejeição pendente na fila de admissão da desagregação, preservando o erro original, antes de qualquer inicialização, alocação ou transferência de KV. A Cloudflare validou as duas alterações com o script de reprodução do pesquisador e seus próprios testes com marcadores canário antes de restaurar o modelo.

Correções upstream e trabalho em andamento

A Cloudflare propôs sua correção ao projeto SGLang por meio da solicitação de pull #38704, e os mantenedores incorporaram a #38935, que rejeita as solicitações afetadas no momento da admissão, seguindo a abordagem da Cloudflare. Uma correção relacionada, a #36988, havia sido incorporada em 6 de setembro de 2026 para um caminho de falha semelhante. O patch foi incluído no SGLang v0.5.20, seguido por atualizações nas versões v0.5.21, lançada em 2 de outubro de 2026, e v0.5.22, lançada em 19 de outubro de 2026. A Cloudflare recomenda que todos os operadores do SGLang atualizem para a v0.5.22 ou posterior. A equipe do SGLang afirma que a v0.5.21 protege por padrão as implantações com Mooncake e NIXL contra todos os tipos de falha, que as implantações com MORI precisam de uma compilação na v0.5.22 e que a linha de correções não foi retroportada para ramificações de versões anteriores.

A equipe do SGLang informou que, em 21 execuções realizadas em duas GPUs H100, as variações de throughput com as proteções ficaram dentro de ±2%, e todos os intervalos de confiança de 95% incluíram zero. Em uma série separada de 16 execuções em duas GPUs H200, o custo de ativar por padrão a liberação diferida de KV foi de −0,38%, com intervalo de confiança de −2,12% a +1,36%, resultado que a equipe descreveu como não significativo. A Cloudflare se reuniu com os responsáveis pela manutenção do SGLang na RadixArk em 10 de setembro de 2026, implementou medidas adicionais de reforço em todas as suas implantações de produção do SGLang entre 11 e 19 de setembro de 2026, e as mesclagens no repositório principal que abrangiam a correção na admissão, as somas de verificação por transferência, a preservação da confirmação de cancelamento e a ativação por padrão da liberação diferida de KV ocorreram de 16 de setembro a 12 de outubro de 2026.

Para outros operadores que executam o SGLang em modo desagregado, o relatório da Cloudflare recomenda medir o pool de KV em relação ao comprimento do contexto em cada nó de pré-preenchimento e de decodificação após qualquer alteração nos pesos, na quantização, no paralelismo ou na fração de memória; atualizar para uma compilação que inclua as duas correções na admissão; manter ativada a liberação diferida de KV em ambas as funções; habilitar a detecção de corrupção quando o modelo for compatível; e configurar os balanceadores de carga para que a desconexão de um cliente não cancele uma solicitação no meio da transferência.

A Cloudflare afirmou que havia desenvolvido anteriormente um protótipo que identifica cada página física de KV e verifica o mapeamento antes que a decodificação leia o cache, e que, nos testes, o custo foi inferior a 1% em throughput e latência de cauda. A empresa testou o protótipo com o GLM 5.2 em meados de agosto de 2026, mas o desativou pouco depois devido a problemas de confiabilidade. A Cloudflare está trabalhando com a equipe do SGLang em uma versão de produção integrada ao mecanismo, tendo como primeiro passo a soma de verificação por transferência na solicitação de pull #39500, e afirmou que está direcionando sua experiência em métodos formais para modelar e provar a segurança de um protocolo de transferência de cache de KV baseado em RDMA que usa Mooncake na implantação de produção do SGLang.

A publicação da equipe do SGLang agradece aos engenheiros da Cloudflare Kevin Flansburg e Kastan Day pelo trabalho nas correções e lista a divulgação coordenada pelo SGLang e pela Cloudflare em 26 de outubro de 2026 como a última entrada na cronologia da divulgação. O relatório do próprio pesquisador, que, segundo a equipe do SGLang, descreverá a descoberta e a validação externa, será publicado em breve.