Cloudflare detalha falha no Workers AI que expôs dados de outros clientes via KV cache

A Cloudflare descreve duas falhas que se somaram. A primeira foi de configuração: o GLM-5.3 (@cf/zai-org/glm-5.3) foi publicado com janela de contexto de 1.048.576 tokens, mas o pool de KV cache nas GPUs de prefill comportava só 681.280 tokens. A empresa diz que conhecia o descompasso antes do lançamento. Os testes de contexto longo devolveram respostas com sucesso, então ela assumiu que o motor trataria o excesso com um erro. O erro foi validar apenas códigos HTTP e desempenho, sem checar a coerência da saída.

A segunda falha estava no SGLang, em modo disaggregated prefill/decode. Um prompt que não cabia no pool era marcado como rejeitado e trocado por um placeholder de um token, mas as filas de admissão checavam req.finished(), que seguia retornando False. O prefill gerava o KV do placeholder e avisava "transfer complete". O nó de decode reservava, por exemplo, 8 páginas, recebia só uma escrita e lia as outras 7 com dados de requisições anteriores. O cliente recebia HTTP 200 em vez de 400. As páginas de KV não são zeradas entre requisições, o que é comum em motores de inferência por desempenho.

No total, foram 155 respostas afetadas, todas para prompts acima de 681.280 tokens, entre 27 de agosto e 9 de setembro de 2026. A Cloudflare não achou evidência de exploração deliberada. A correção veio na configuração (pool de cerca de 2,04 milhões de tokens, igual ao do GLM 5.2) e no motor (requisição rejeitada é encerrada na fila de admissão, com o erro original). O patch saiu no SGLang v0.5.20, com ajustes nas v0.5.21 e v0.5.22, e a empresa recomenda v0.5.22 ou superior.

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 de Gadi Evron, da Knostic, em 8 de setembro e a falha presente desde 27 de agosto. Agora a Cloudflare publica o relato técnico completo: a causa em duas camadas (pool menor que o contexto e o bug de rejeição no SGLang), a contagem de 155 respostas e as versões do SGLang com correção.

Para quem opera inferência própria com SGLang, a leitura é direta: confira o tamanho do pool de KV contra o contexto anunciado, direto no motor em execução, e não por código de status. Para quem só consome a API, o caso mostra que HTTP 200 e resposta coerente não provam isolamento entre tenants.