Cloudflare corrige exposição de KV cache entre requisições no GLM-5.3 do Workers AI com atualização do SGLang

O problema não foi um ataque sofisticado, e sim a soma de duas falhas. A primeira foi de configuração: a Cloudflare publicou o GLM-5.3 com janela de contexto de 1.048.576 tokens, mas o KV pool das GPUs de prefill comportava só 681.280. A empresa conhecia essa diferença antes do lançamento e presumiu que o motor devolveria erro para prompts grandes demais. Os testes de contexto longo retornaram sucesso, e a validação se limitava a códigos de status HTTP, sem checar coerência da saída.

A segunda falha estava no SGLang em modo disaggregated. A requisição acima do limite era marcada como rejeitada e trocada por um placeholder de um token, mas as filas de admissão checavam finished(), não a rejeição. O prefill gerava o KV de um token e o enviava ao decode, que reservara páginas para o prompt inteiro e recebia um "transfer complete". As páginas não sobrescritas ainda guardavam prompts e gerações de outros usuários. Resultado: HTTP 200, resposta coerente e dados alheios, em 155 respostas entre 27 de agosto e 9 de setembro de 2026. A Cloudflare não achou indício de exploração deliberada, e só o GLM-5.3 foi afetado. O pesquisador Gadi Evron, da Knostic, reportou em 8 de setembro, o modelo saiu do ar em até 40 minutos após a declaração do incidente e voltou em 9 de setembro.

Em 26 de outubro de 2026, o CEVIU noticiou "Cloudflare corrige falha no Workers AI que expôs dados entre clientes no modelo GLM-5.3", com o alerta do pesquisador e a data de início. Em 27 de outubro de 2026, o CEVIU publicou "Cloudflare detalha falha no Workers AI que expôs dados de outros clientes via KV cache", com o número de 155 respostas e a combinação de incompatibilidade de capacidade com bug de tratamento de erros. A cobertura de hoje acrescenta o foco operacional: a correção no SGLang (v0.5.22 ou posterior), a checagem do KV pool contra o tamanho do contexto em cada nó e o uso de --disaggregation-enable-kv-checksum quando o modelo oferecer suporte.

Para quem opera inferência própria com SGLang disaggregated, a leitura é direta: o tamanho do KV pool é calculado na inicialização a partir da memória que sobra após carregar os pesos, e nada obriga esse valor a bater com o contexto anunciado. Isso vira item de checklist de deploy. Também mostra que teste de status HTTP não prova isolamento entre tenants, e que páginas de cache não zeradas dependem inteiramente de o motor rastrear a posse corretamente.