O conjunto reúne duas falhas de autenticação vinculada à conexão, uma delas crítica em HTTP/3, além de um alvo de requisição sem raiz que escapa do roteamento por caminho, um bypass da sanitização de cabeçalhos por trailers e um contrabando de requisições pelo upgrade h2c. As correções estão em 2.11.57 e 3.7.13.
Aplicativo
Traefik
Data do compilado
Vulnerabilidades
5
A falha crítica exige HTTP/3 ativado e backend com NTLM ou Negotiate. A falha de trailers depende de o operador usar delete ou reject, ou de o backend confiar em X-Forwarded-*, e o valor só chega ao backend com um middleware que lê o corpo antes do proxy. A do upgrade h2c exige um backend que aceite o upgrade sem validar a lista Connection. A indicação de correção descreve as versões do projeto e não confirma a atualização da sua instância.
Gravidade críticaCorreção disponível
HTTP/3 reaproveita conexão de backend autenticada por NTLM ou Negotiate
O caminho de requisição HTTP/3 não inicializa o suporte de transporte vinculado à conexão que isola a autenticação NTLM e Negotiate nos caminhos HTTP/1.1 e HTTP/2. O entrypoint HTTP/3 reaproveita a cadeia de handlers do HTTPS e chega ao mesmo round tripper de backend, mas o ConnContext não chama a função que instala o transporte por conexão. Sem esse suporte, o kerberosRoundTripper usa o transporte compartilhado. Em uma rota servida por HTTP/3 para um backend que vincula a identidade à conexão persistente, um cliente HTTP/3 sem relação com a vítima pode receber uma conexão de backend já autenticada como ela e herdar a identidade, lendo conteúdo restrito e executando ações em nome da vítima sem apresentar credencial.
Casos de uso afetados
Você ativa HTTP/3 em um entrypoint e encaminha para um backend com NTLM ou Negotiate e keep-alive. Um segundo cliente HTTP/3 sem credenciais pode ler conteúdo exclusivo da vítima e executar uma transferência em nome dela.
Você mantém HTTP/3 para reduzir latência em aplicações internas com autenticação integrada do Windows. A conexão autenticada por um usuário pode ser entregue a outro cliente que alcance a mesma rota.
Confira na sua instância
Confira se o entrypoint tem http3 configurado e identifique backends com NTLM ou Negotiate. No backend, acompanhe o identificador das conexões TCP e o usuário associado a cada uma, procurando a mesma conexão atendendo usuários diferentes. Compare o controle por HTTP/1.1, que deve isolar a conexão, com o acesso por HTTP/3. Depois de atualizar para 2.11.57 ou 3.7.13, repita o teste com dois clientes HTTP/3 e confirme que o segundo não herda a identidade do primeiro.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.11.x
>= v3.0.0, <= v3.7.12
v3.7.13
3.x
>= v2.11.0, <= v2.11.56
v2.11.57
A falha exige HTTP/3 no entrypoint, backend com NTLM ou Negotiate e reutilização de conexão. Aplicações com autenticação por requisição não são afetadas. A linha 3.0 a 3.6 está fora de manutenção e exige atualização para 3.7.13.
Gravidade altaCorreção disponível
Alvo de requisição sem raiz é roteado como / e encaminhado literal ao backend
O Traefik aceita uma requisição HTTP/1.x cujo request-target está em forma sem raiz, como GET http:http://internal-vhost/admin HTTP/1.1. O Go interpreta isso como URL.Opaque, com URL.Path vazio, então o Traefik decide roteamento, sanitização de caminho, middlewares e log de acesso sobre um caminho que vira /. O proxy, porém, encaminha o alvo original byte a byte ao backend. Guardas de caminho e prefixo, políticas de ForwardAuth por caminho e o endurecimento de encodedCharacters nunca veem o alvo real, e o log registra GET / HTTP/1.1. Em um backend que resolve o alvo sem raiz como caminho, isso permite selecionar outro host virtual, furar autorização por caminho e esconder o acesso do log, sem autenticação e com a configuração padrão do entrypoint.
Casos de uso afetados
Você usa ForwardAuth com rota que nega caminhos iniciados por /admin. O alvo sem raiz não casa com a rota, a autenticação libera e o backend recebe /admin.
Você separa hosts virtuais no mesmo backend e confia no roteamento por Host do Traefik. A forma sem raiz leva o backend a atender outro host virtual.
Você ativa encodedCharacters.allowEncodedSlash como false e espera recusar %2f no caminho. O endurecimento não vê a forma sem raiz e o payload chega ao backend.
Confira na sua instância
Confirme a versão do Traefik e quais backends aceitam alvos sem raiz: fasthttp e o servidor http.server do Python aceitam, enquanto Go net/http, nginx, Apache, Node.js e Tomcat respondem 400. Procure no log de acesso requisições registradas como GET / que tenham chegado a caminhos diferentes no backend. Em ambiente de teste, envie a forma sem raiz para uma rota protegida e confirme o resultado. Depois de atualizar para 2.11.57 ou 3.7.13, repita o envio e confirme que o alvo é recusado ou normalizado antes do roteamento.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.x
>= v3.0.0, <= v3.7.12
v3.7.13
3.x
<= v2.11.56
v2.11.57
A falha vale para os dois proxies, o padrão e o FastProxy experimental. O efeito prático depende de o backend aceitar o alvo sem raiz como caminho. A linha 3.0 a 3.6 está fora de manutenção e exige atualização para 3.7.13.
Gravidade altaCorreção disponível
Trailers escapam da sanitização de nomes de cabeçalho do entrypoint
As defesas do entrypoint contra nomes de cabeçalho falsificados, como aliasHeadersStrategy e underscoreHeadersStrategy em modo delete ou reject e a remoção padrão de X-Forwarded-* enviados pelo cliente, percorrem apenas req.Header e nunca req.Trailer. Um cliente sem autenticação pode enviar o nome saneável, como X_Auth_User ou X-Forwarded-Prefix, como trailer HTTP/1.1 em chunks ou como trailer HTTP/2. O modo reject não devolve o 400 previsto, o modo delete não remove o nome, e o proxy encaminha o trailer ao backend. Com um middleware que lê o corpo antes do proxy, como retry com status ou buffering, o valor escolhido pelo atacante também chega. Backends que juntam trailers ao espaço de cabeçalhos agem sobre o nome contrabandeado.
Casos de uso afetados
Você ativa aliasHeadersStrategy em reject para fechar a falsificação por grafias alternativas. Um cliente envia X_Auth_User como trailer, recebe 200 em vez de 400 e o nome chega ao backend.
Você depende da remoção padrão de X-Forwarded-* para clientes não confiáveis. O backend junta trailers aos cabeçalhos e aceita X-Forwarded-Prefix enviado como trailer com valor escolhido pelo atacante.
Você usa o middleware retry com códigos de status ou o buffering na cadeia. O corpo é lido antes do proxy, o trailer viaja com valor e a política de presença do backend é invertida.
Confira na sua instância
Confira as opções aliasHeadersStrategy, underscoreHeadersStrategy e forwardedHeaders nos entrypoints e se há middlewares retry com status ou buffering nas rotas. Procure no backend registros de trailers recebidos com nomes que deveriam ter sido removidos. Em ambiente de teste, envie uma requisição chunked com Trailer apontando para X_Auth_User e confirme o comportamento. Depois de atualizar para 3.7.13, repita o envio e confirme que o valor do trailer não chega ao backend.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.2 a 3.7
>= v3.2.0, <= v3.7.12
v3.7.13
A falha está no proxy próprio do Traefik 3, introduzido na linha 3.2. O Traefik 2 usa o ReverseProxy da biblioteca padrão do Go e não encaminha valores de trailer. A linha 3.2 a 3.6 está fora de manutenção e exige atualização para 3.7.13.
Gravidade altaCorreção disponível
Upgrade h2c iniciado pelo cliente cria túnel que ignora roteamento e middlewares
O Traefik encaminha ao backend o cabeçalho Upgrade enviado pelo cliente, sem restringir o token a protocolos que ele mesmo suporta. Quando o backend aceita um upgrade h2c e responde 101 Switching Protocols, o Traefik coloca a conexão em modo de túnel de bytes e deixa de aplicar o roteamento HTTP e a cadeia de middlewares. Um cliente pode usar uma rota sem autenticação que aponte para o mesmo backend, abrir o túnel e enviar requisições HTTP/2 para caminhos protegidos. Essas requisições não passam pelo router nem pelos middlewares da rota protegida, e também não aparecem no log de acesso, nas métricas e no tracing. A correção deixa de encaminhar o token Upgrade h2c e o cabeçalho HTTP2-Settings, sem alterar o Upgrade websocket.
Casos de uso afetados
Você publica /public sem autenticação e /admin com BasicAuth no mesmo backend. O atacante abre o túnel por /public e acessa /admin sem credencial.
Você protege caminhos com IPAllowList ou RateLimit. As requisições enviadas pelo túnel não passam por essas restrições.
Você depende do log de acesso para identificar acessos indevidos. As requisições dentro do túnel não aparecem coma requisiçãos individuais.
Confira na sua instância
Confirme a versão do Traefik e se algum backend aceita Upgrade: h2c com 101. Verifique quais rotas sem autenticação apontam para o mesmo backend de rotas protegidas. Em ambiente de teste, envie Upgrade: h2c por uma rota pública, confirme o 101 e tente uma requisição HTTP/2 a um caminho protegido. Depois de atualizar para 2.11.57 ou 3.7.13, repita e confirme que o upgrade h2c não é encaminhado.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.11.x
>= v3.4.2, <= v3.7.12
v3.7.13
3.4 a 3.7
>= v2.11.26, <= v2.11.56
v2.11.57
A exploração exige um backend que aceite o upgrade h2c sem validar a lista Connection. Servidores comuns testados não foram exploráveis. A falha não depende de o operador configurar h2c no serviço. A linha 3.4 a 3.6 está fora de manutenção e exige atualização para 3.7.13.
Gravidade moderadaCorreção disponível
BasicAuth revela nomes de usuário pela latência em requisições simultâneas
O middleware BasicAuth agrupa verificações simultâneas de credencial em um singleflight. Desde 3.6.11, a chave do agrupamento era montada com a senha enviada e o segredo armazenado, o que depende do estado do servidor. Todos os nomes inexistentes caem em uma mesma chave, enquanto cada nome configurado tem a própria. Sob concorrência controlada pelo atacante, uma sonda que chega durante o cálculo de uma requisição líder recebe o resultado rápido quando o nome não existe e calcula o próprio hash, mais lento, quando o nome existe. Isso reintroduz a diferença de tempo que revela se um usuário existe, apenas no caso simultâneo; a sondagem sequencial continua equalizada. A correção monta a chave apenas com usuário e senha enviados, sem usar o segredo armazenado. O efeito se limita à descoberta de nomes de usuário, sem vazamento de credencial nem bypass de autenticação.
Casos de uso afetados
Você expõe uma rota com BasicAuth e um atacante já conhece uma senha comum. Com requisições simultâneas, ele confirma quais nomes de usuário existem pela diferença de latência.
Você usa nomes de usuário previsíveis ou corporativos e depende da equalização de tempo do BasicAuth. A descoberta de nomes reduz o esforço de uma tentativa posterior de credencial.
Confira na sua instância
Confira a versão do Traefik e as rotas com BasicAuth. Meça a latência de uma sonda sequencial para um usuário existente e para um inexistente como controle; depois repita com requisições simultâneas e compare. No log de acesso, procure sequências de tentativas com nomes variados na mesma janela. Depois de atualizar para 3.7.13, repita a medição concorrente e confirme que os tempos deixam de distinguir a existência do usuário.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.6 a 3.7
>= v3.6.11, <= v3.7.12
v3.7.13
O Traefik 2 não é afetado, porque o BasicAuth da linha 2.11 não usa singleflight. O digestAuth também não é afetado. A linha 3.6 está fora de manutenção e exige atualização para 3.7.13.
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.
