Em 25 de outubro de 2026, a Cloudflare publicou um lançamento emergencial do WAF que coloca em produção, sem exigir opt-in, duas regras ativadas por padrão em modo Log para a CVE-2026-111497, uma falha de buffer overflow no decodificador do Brotli. A mudança alcança duas audiências ao mesmo tempo: equipes que usam o Cloudflare Managed Ruleset na frente de suas aplicações e equipes que mantêm bibliotecas Brotli em proxies, gateways de API e servidores que descomprimem corpos de requisição enviados por clientes. A ação prioritária é dupla e imediata: revisar overrides de bloqueio no ruleset antes que as regras entrem em vigor e inventariar as versões do Brotli em uso para aplicar as correções já publicadas.
O que mudou na plataforma
O Cloudflare Managed Ruleset é mantido e atualizado pela própria Cloudflare, e este release emergencial introduziu duas detecções inéditas com ação padrão Log: as regras registram as requisições que casam, mas não as interrompem. A primeira regra casa requisições que declaram corpo comprimido em Brotli, identificadas pelo cabeçalho Content-Encoding: br. A segunda casa chamadas ao endpoint de otimização de imagens do Next.js, o caminho /_next/image. A escolha por Log em vez de Block é deliberada: os dois padrões de tráfego são legítimos em muitas aplicações, e a plataforma quer dar visibilidade antes de deixar cada cliente decidir pelo bloqueio.
Dois limites precisam ficar claros para não superestimar a cobertura. A regra Brotli não casa o cabeçalho Accept-Encoding: br, usado apenas para negociar compressão de resposta, e não altera as configurações de compressão de resposta da própria Cloudflare. E o modo Log, sozinho, não interrompe nenhum ataque: é um instrumento de medição, não uma barreira. Quem tratar o deploy como proteção efetiva vai descobrir, no pior momento, que a regra só acumulou eventos que ninguém leu. A decisão de bloquear continua sendo do cliente — e é exatamente por isso que a revisão de configuração antiga pesa mais que a novidade em si.
Como a falha do Brotli funciona
Segundo o registro do NVD, publicado em 22 de outubro de 2026 com o Google como fonte da informação, trata-se de um buffer overflow no arquivo c/dec/decode.c do decodificador. O problema afeta as versões 1.0.3 até 1.2.0 do decodificador em todas as plataformas e permite que um atacante remoto não autenticado corrompa regiões adjacentes de memória do estado do decodificador, exponha conteúdo sensível de memória, provoque negação de serviço ou, no cenário mais grave, execute código arbitrário — tudo a partir de um fluxo comprimido malicioso entregue a um serviço que descomprime a entrada enviada pelo cliente.
O vetor prático é a descompressão de dados controlados por quem faz a requisição. A maioria dos times só enxerga o Brotli como compressão de resposta para navegadores, mas gateways, proxies reversos e aplicações que aceitam corpos de requisição comprimidos decodificam exatamente o que o cliente envia, e é esse caminho que interessa ao atacante. A correção indicada é atualizar para 1.0.10, 1.1.1 ou 1.2.1, conforme a linha de versão em uso; bibliotecas e binários na faixa afetada seguem expostos até a atualização. O registro classifica o problema como escrita fora dos limites (CWE-787), e o NVD ainda não publicou avaliação própria de severidade — mais um motivo para priorizar por exposição real, não por nota.
O risco dos overrides de bloqueio
O detalhe que pode derrubar produção nesta mudança não é a regra nova, e sim a configuração antiga. Um override de Block herdado do ruleset, aplicado no nível do conjunto de regras, transforma a ação padrão Log em bloqueio real no momento do deploy, sem que a equipe tenha pedido isso. O resultado previsível é falso positivo em massa: clientes móveis que enviam corpos Brotli legítimos passam a receber erro e aplicações Next.js cujas imagens otimizadas param de carregar. A recomendação da Cloudflare é revisar os overrides existentes antes do deploy e, quando a intenção é avaliar com segurança, configurar overrides específicos por regra em Log, medir os casamentos e só então promover para Block.
O que cada regra captura
| Regra | Padrão casado | Ação padrão | Risco de falso positivo | Recomendação |
|---|---|---|---|---|
| Brotli | Corpo de requisição com Content-Encoding: br | Log | Clientes legítimos que comprimem corpos de requisição | Medir volume por janela definida antes de bloquear |
| Next.js | Chamadas ao endpoint /_next/image | Log | Tráfego legítimo de otimização de imagens | Avaliar exposição do endpoint e decidir por aplicação |
Prioridades de resposta P1 e P2
- P1 — Inventariar e corrigir o Brotli: mapear proxies, gateways e serviços que descomprimem entrada do cliente, confirmar a versão da biblioteca em cada ponto e aplicar a versão corrigida da linha correspondente. O WAF enxerga a borda; a falha mora dentro do processo que decodifica.
- P1 — Revisar overrides do Managed Ruleset: exportar a configuração atual e procurar qualquer override de ação em nível de ruleset. Block herdado nesta estrutura vira bloqueio imediato quando a regra entra no ar.
- P2 — Medir antes de bloquear: acompanhar os eventos de WAF em analytics por uma janela definida, comparar com a linha de base de tráfego legítimo e só então promover uma regra por vez para Block, com rollback documentado.
- P2 — Verificar exposição do /_next/image: se a otimização de imagens é pública e usada por clientes legítimos, o bloqueio tem custo direto de experiência; decida por aplicação, não por conta.
Como auditar sem quebrar tráfego
- Exporte a configuração do Managed Ruleset e liste todo override de ação; qualquer Block em nível de ruleset precisa de justificativa registrada.
- Garanta retenção dos eventos de segurança e defina a janela de observação antes de qualquer discussão sobre bloqueio.
- Em ambiente de staging, envie uma requisição de teste com Content-Encoding: br e confirme que ela aparece nos eventos casando com a regra nova.
- Compare o volume de casamentos com a linha de base de tráfego legítimo; falso positivo confirmado vira override específico em Log, não desligamento da detecção.
- Somente depois da medição promova a regra para Block, uma por vez, com plano de reversão pronto.
Plataformas que aplicam segurança por padrão encurtam o tempo de reação, mas transferem ao cliente a decisão de endurecer de fato. O mesmo raciocínio vale para quem administra regras de admissão sem webhook no Kubernetes e para quem modela controles de perímetro no Google Cloud: o controle nativo só protege de verdade quando a equipe revisa o que ele já bloqueia e o que ainda apenas observa.