A Cloudflare publicou em 12 de novembro de 2026 o cloudflared 2026.11.0, versão do agente que mantém o Cloudflare Tunnel aberto entre o servidor e a rede da Cloudflare. Ela amplia a normalização de URL que chegou na 2026.10.0, em 22 de outubro, e muda a data em que esse comportamento passa a ser o padrão: novas versões do cloudflared publicadas a partir de 8 de fevereiro de 2027 virão com a normalização ligada. O anúncio anterior falava em 25 de janeiro.
O que a normalização faz no roteamento
O Tunnel escolhe para qual serviço mandar cada requisição comparando o hostname e, opcionalmente, o caminho com uma lista de regras de entrada (ingress). As regras são lidas de cima para baixo e a primeira que casa vence. O campo path aceita uma expressão regular.
Com a normalização ativa, o cloudflared limpa o caminho antes dessa comparação. Segundo a documentação, ele resolve segmentos . e .., troca barras invertidas por barras normais e junta barras repetidas. A versão 2026.11.0 acrescenta a remoção de parâmetros separados por ponto e vírgula, como em /admin;x=1/. O caminho enviado à aplicação continua o original: /hello/../path casa com a regra de /path, mas a origem recebe /hello/../path.
A Cloudflare apresenta a mudança como reforço de segurança para regras que exigem validação do Cloudflare Access, o parâmetro access com required: true. Nesse modo, o cloudflared confere o token JWT do Access antes de repassar o tráfego para a origem.
Quem precisa olhar a configuração
A documentação diz que configurações sem regras de validação do Access não são afetadas. O grupo que precisa revisar é mais estreito: times que expõem aplicações internas pelo Tunnel, protegem parte delas com access.required e usam regras com path para separar o que é protegido do que não é. Um painel administrativo publicado no mesmo hostname do site, com uma regra só para /admin, é o formato típico.
Minha leitura do motivo, que a Cloudflare não detalha: quando a regra protegida depende de uma expressão regular sobre o caminho, uma URL escrita de outro jeito (com .., barra dobrada ou ;) pode não casar com essa regra e cair numa regra seguinte sem validação, enquanto o servidor de aplicação interpreta o mesmo caminho como a área protegida. A normalização faz o cloudflared comparar a forma que a origem provavelmente vai entender.
Isso tem dois efeitos práticos. Enquanto a normalização estiver desligada, uma configuração assim depende de a expressão regular cobrir todas as variações de escrita do caminho. Quando ela for ligada, requisições que hoje caem numa regra podem passar a cair em outra, e uma rota que funciona hoje pode mudar de destino.
O que fazer antes de 8 de fevereiro
Para quem está no grupo acima, o trabalho cabe numa tarefa de manutenção:
- atualizar o
cloudflaredpara 2026.11.0 ou posterior em todas as réplicas do túnel; - ligar a normalização num ambiente de teste com
cloudflared tunnel --disable-path-normalization=false run <túnel>ou com a variávelTUNNEL_DISABLE_PATH_NORMALIZATION=false, reiniciando cada réplica; - conferir com
cloudflared tunnel ingress rule <URL>qual regra cada caminho importante atinge, incluindo variações com..,//e;; - só então ligar em produção, sem esperar a mudança de padrão.
Há uma razão para não deixar a data decidir. A data vale para versões novas, não para o túnel que já está rodando. Quem fixa a versão do cloudflared numa imagem ou num pacote continua sem normalização até atualizar, e quem atualiza no automático depois de 8 de fevereiro recebe a mudança de roteamento sem ter testado.
Para quem não usa validação do Access no Tunnel, nada muda agora.
O que a Cloudflare ainda não explicou
Os dois avisos falam em "melhorar a segurança" sem descrever uma falha, um CVE ou um caso de acesso indevido. Também não dizem se a normalização vai continuar restrita às regras com Access depois de virar padrão, nem se a data de 8 de fevereiro pode mudar de novo, como já mudou uma vez. Até que isso apareça, a conduta segura é tratar regras de caminho na frente de aplicações protegidas como algo que precisa de teste explícito, com ou sem a flag.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
