Uma falha do provedor ingress-nginx entrega o backend protegido por uma rota irmã de redirecionamento sem aplicar autenticação. Outra permite forjar a identidade do ForwardAuth com um alias pontuado do cabeçalho. A terceira mantém o readTimeout inoperante em HTTP/3 e deixa o upload lento sem limite. As correções estão em 2.11.56 e 3.7.12.
Aplicativo
Traefik
Data do compilado
Vulnerabilidades
3
A correção do ForwardAuth inclui uma opção nova, aliasHeadersStrategy, que vem com o valor keep e precisa ser definida como delete ou reject para valer. A falha de HTTP/3 recebeu CVSS 5.3 e mantém a classificação moderada. A do provedor ingress-nginx afeta apenas a linha 3.7. A indicação de correção descreve as versões do projeto e não confirma a atualização da sua instância.
Gravidade altaCorreção disponível
Rota irmã de from-to-www-redirect entrega backend protegido sem autenticação
Em um Ingress que combina uma anotação de autenticação e nginx.ingress.kubernetes.io/from-to-www-redirect, o provedor ingress-nginx cria uma segunda rota que casa apenas o host, carrega somente o middleware RedirectRegex e aponta para o serviço de backend original. O RedirectRegex não encerra o tratamento: uma requisição que não casa com o padrão segue para o próximo handler, que nessa rota é o backend. O padrão do redirecionamento só aceita porta numérica, enquanto o matcher de host do Traefik normaliza qualquer autoridade. Uma requisição com Host: www.example.com:x seleciona a rota irmã, não casa com o redirecionamento e chega ao backend protegido sem os middlewares derivados das anotações, incluindo autenticação e lista de origens permitidas.
Casos de uso afetados
Você usa from-to-www-redirect junto com autenticação em um Ingress. Um cliente pode enviar o host com porta vazia ou não numérica e alcançar o backend sem credencial.
Você protege o backend com whitelist-source-range em vez de autenticação. A rota irmã também descarta essa restrição e aceita qualquer origem.
Você depende de caminhos específicos no Ingress. A rota irmã não tem PathPrefix e aceita qualquer caminho, inclusive os que não aparecem na configuração.
Confira na sua instância
Procure Ingresses que combinem from-to-www-redirect com auth-type, auth-url ou whitelist-source-range. Confira a versão do provedor ingress-nginx em uso. Em ambiente de teste, envie uma requisição ao host com porta vazia, como Host: www.example.com:, e observe se o backend responde sem autenticação. Depois de atualizar para 3.7.12, repita a requisição e confirme que ele é redirecionado sem alcançar o backend.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.7.x
>= v3.7.0, <= v3.7.11
v3.7.12
O tratamento de from-to-www-redirect entrou no provedor em 3.7.0, então o Traefik 2 e versões 3 anteriores não são afetados. A falha descarta todos os middlewares derivados de anotação na rota irmã, além da autenticação.
Gravidade moderadaCVSS: 5,3/10Correção disponível
readTimeout não vale em HTTP/3 e permite upload lento sem limite
As opções de respondingTimeouts não são aplicadas ao caminho de requisição HTTP/3. O readTimeout, ativado por padrão em 60 segundos, é aplicado como prazo na conexão TCP, que não alcança um stream QUIC, e o servidor HTTP/3 do Traefik é criado sem nenhum timeout. Um cliente sem autenticação que envia o corpo aos poucos mantém a requisição aberta pelo tempo que quiser e, com ela, uma conexão de backend por requisição, com custo mínimo para o atacante. Backends com pool de conexões limitado sentem primeiro. A falha entrou em 2.8.2, quando uma mudança de API do quic-go removeu o http.Server embutido que carregava esses tempos.
Casos de uso afetados
Você ativa HTTP/3 em um entrypoint HTTPS e usa o readTimeout de 60 segundos para encerrar uploads lentos. Um cliente pode manter a requisição aberta indefinidamente e consumir conexões do backend.
Você atende um backend com pool de conexões pequeno. Poucos uploads lentos ocupam todas as conexões disponíveis e reduzem o atendimento aos demais clientes.
Confira na sua instância
Confira se http3 está configurado no entrypoint e qual readTimeout está em uso. Compare o tempo de vida das conexões de backend em uploads lentos por HTTP/1.1 e por HTTP/3. No backend, procure conexões abertas durante muito tempo com corpo incompleto. Depois de atualizar para 2.11.56 ou 3.7.12, repita o upload lento por HTTP/3 e confirme que a conexão é encerrada no prazo configurado.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.x
>= v2.8.2, <= v2.11.55
v2.11.56
3.x
>= v3.0.0, <= v3.7.11
v3.7.12
A falha alcança da 2.8.2 em diante, quando o caminho HTTP/3 perdeu os tempos herdados do http.Server. Versões anteriores à 2.8.2 não são afetadas. Enquanto a atualização não acontece, limite o tamanho do corpo aceito no backend e mantenha o HTTP/3 restrito às redes que exigem o protocolo.
Gravidade moderadaCorreção disponível
Alias com pontos burla o cabeçalho de identidade do ForwardAuth
O Go normaliza nomes de cabeçalho apenas pelo hífen, então X-Auth-User, X_Auth_User e X.Auth.User são três cabeçalhos distintos para o Traefik. Backends que derivam nomes de variáveis a partir do cabeçalho, como CGI, WSGI, PHP e NGINX, juntam os três na mesma variável. O ForwardAuth remove e substitui apenas a chave canônica configurada em authResponseHeaders. Um cliente pode enviar um alias pontuado, como X.Authenticated.User, junto do cabeçalho canônico escrito pelo middleware. No caminho HTTP/1, o valor do cliente é serializado depois e prevalece no backend, que lê a identidade escolhida pelo atacante no lugar da identidade confirmada pelo ForwardAuth. Qualquer cabeçalho definido pelo Traefik fica exposto, e também os do ForwardAuth.
Casos de uso afetados
Você usa ForwardAuth para autenticar e repassa a identidade por cabeçalho a uma aplicação PHP. Um cliente autorizado como usuário comum pode enviar o alias pontuado e ser tratado como administrador.
Você confia em cabeçalhos definidos pelo Traefik para separar papéis ou locatários. O alias pontuado substitui o valor no backend e rompe a separação.
Confira na sua instância
Confira a versão do Traefik e o valor de aliasHeadersStrategy nos entrypoints. Depois de atualizar para 2.11.56 ou 3.7.12, defina aliasHeadersStrategy como delete ou reject. Em ambiente de teste, envie uma requisição com X.Authenticated.User e outro com X-Authenticated-User e confirme que o backend lê apenas a identidade definida pelo ForwardAuth. Verifique nos logs se a requisição com alias é recusado ou se o cabeçalho é removido antes do encaminhamento.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.x
<= v2.11.55
v2.11.56
3.x
>= v3.0.0, <= v3.7.11
v3.7.12
A opção aliasHeadersStrategy vem com keep para preservar o comportamento anterior e só atua quando definida como delete ou reject. A falha não recusa uma autenticação legítima: o serviço de autenticação precisa primeiro permitir a requisição. O efeito foi confirmado em PHP 8.2, onde as duas grafias viram a mesma variável de servidor.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
