Os nove avisos abrangem a exigência de certificados de cliente, o isolamento da autenticação nos backends e os controles de acesso do provedor Kubernetes Ingress NGINX. Você precisa comparar a versão instalada com as faixas de cada ficha e conferir as configurações que tornam a falha aplicável. As correções constam nas releases [v2.11.58](https://github.com/traefik/traefik/releases/tag/v2.11.58), [v3.7.13](https://github.com/traefik/traefik/releases/tag/v3.7.13) e [v3.7.14](https://github.com/traefik/traefik/releases/tag/v3.7.14), conforme o aviso.
Aplicativo
Traefik
Data do compilado
Vulnerabilidades
9
As pontuações são do CVSS 4.0 informado nos avisos. A indicação de correção descreve a disponibilidade no projeto, não confirma que sua instância foi atualizada. As conferências de comportamento devem ser feitas em homologação.
Gravidade altaCVSS: 7,0/10Correção disponível
FastProxy pode reutilizar a identidade autenticada de outro cliente
O pool de conexões do FastProxy agrupa conexões pelo ServersTransport e pela URL de destino, mas não preserva o isolamento necessário à autenticação NTLM ou Negotiate vinculada à conexão. Em um backend HTTP com keep-alive, uma conexão já autenticada pode ser entregue a outro cliente. Esse cliente consegue acessar informações restritas e executar ações com a identidade anterior sem apresentar credenciais.
Casos de uso afetados
Sua instância tem experimental.fastProxy habilitado e encaminha requisições para um backend http:// que mantém a autenticação NTLM ou Negotiate na conexão.
O backend conserva conexões abertas com keep-alive, permitindo que o pool reutilize uma conexão após a autenticação de um cliente.
Confira na sua instância
Confira experimental.fastProxy na configuração estática e identifique os serviços com destinos http://. Nos backends que usam NTLM ou Negotiate, verifique se há keep-alive. Após atualizar, use contas de teste e conexões de cliente separadas em homologação para confirmar que uma conexão sem credenciais não recebe a identidade da conexão autenticada.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v3
>= v3.2.0, <= v3.7.13
v3.7.14
Esta falha pertence ao FastProxy experimental. A implementação padrão do proxy não é afetada por este aviso. As linhas v3.2 a v3.6 precisam migrar para v3.7.14 porque não receberão uma correção própria.
Gravidade altaCVSS: 7,0/10Correção disponível
Configuração TLS de um serviço pode ser aplicada a outro
Depois de receber um desafio NTLM ou Negotiate, o Traefik associa um transporte dedicado à conexão do cliente. Esse transporte também contém as configurações TLS do ServersTransport original. A falha permite reutilizá-lo ao acessar outro serviço pela mesma conexão, aplicando ao segundo backend as autoridades certificadoras, a validação do servidor e o certificado de cliente do primeiro serviço. O desafio inicial já permite preparar essa troca, sem exigir uma autenticação concluída.
Casos de uso afetados
Você publica serviços com ServersTransport distintos e pelo menos um backend responde com WWW-Authenticate: NTLM ou Negotiate.
Um cliente consegue acessar esses serviços pela mesma conexão persistente, embora cada backend tenha exigências diferentes de confiança TLS ou certificado de cliente.
Confira na sua instância
Compare os ServersTransport dos serviços acessíveis pela mesma conexão e identifique os backends que emitem desafios NTLM ou Negotiate. Em homologação, após atualizar, confira os registros TLS de dois backends de teste com configurações distintas. Cada destino deve receber somente o certificado de cliente previsto para seu transporte e manter sua própria validação de certificado do servidor.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v2
>= v2.11.0, <= v2.11.57
v2.11.58
github.com/traefik/traefik/v3
>= v3.0.0, <= v3.7.13
v3.7.14
A correção mantém um transporte dedicado por ServersTransport. O Traefik v1 e as versões v2 anteriores a v2.11.0 não são afetados. As linhas v3.0 a v3.6 precisam migrar para v3.7.14.
Gravidade altaCVSS: 7,0/10Correção disponível
Build com Go 1.27 pode ignorar a conferência de SNI
A conferência de SNI verifica se as opções TLS do roteador HTTP correspondem às negociadas na conexão. O Traefik ignora essa conferência quando req.TLS está vazio. Nos builds com Go 1.27, uma requisição HTTP/2 com o pseudo-header :scheme http pode chegar nessa condição mesmo sobre uma conexão TLS. Isso permite alcançar um roteador com exigências diferentes, inclusive um que exige certificado de cliente, sem apresentar esse certificado.
Casos de uso afetados
Você executa um build próprio ou uma imagem de terceiros compilada com Go 1.27 e aceita HTTP/2 sobre TLS.
Os roteadores acessíveis possuem opções TLS diferentes, como um domínio sem autenticação por certificado e outro que exige certificado de cliente.
Confira na sua instância
Confira a versão do Go usada para compilar o binário efetivamente executado, consultando seus metadados ou o registro do build. Não conclua pela versão do Traefik isoladamente. Em homologação, valide após a atualização que requisições HTTP/2 sobre TLS continuam sujeitas à compatibilidade das opções do roteador, inclusive quando o pseudo-header :scheme informa http.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v2
<= v2.11.57
v2.11.58
github.com/traefik/traefik/v3
>= v3.0.0, <= v3.7.13
v3.7.14
Segundo o aviso, os binários e as imagens oficiais utilizam Go 1.26 e não estão expostos a esta falha. A condição descrita depende de compilação com Go 1.27. As versões v3 anteriores à linha v3.7 precisam migrar para uma versão mantida e corrigida.
Gravidade altaCVSS: 7,0/10Correção disponível
Rota HTTP pode aceitar cabeçalhos falsos de identidade por certificado
No provedor Kubernetes Ingress NGINX, o middleware responsável pelos cabeçalhos Ssl-Client-* é associado somente ao roteador TLS. A rota HTTP do mesmo Ingress encaminha os valores recebidos do cliente. Quando ssl-redirect está desativado, essa rota chega ao backend e pode transportar uma declaração falsa de certificado validado. Um backend que confia nesses cabeçalhos como identidade de autenticação mútua TLS pode autorizar o acesso sem que um certificado tenha sido apresentado.
Casos de uso afetados
Seu Ingress usa nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream e nginx.ingress.kubernetes.io/ssl-redirect: "false".
O backend autoriza requisições a partir dos cabeçalhos Ssl-Client-* e também pode ser alcançado pela rota HTTP sem TLS.
Confira na sua instância
Revise as duas anotações no Ingress e confira se o backend utiliza Ssl-Client-* para reconhecer a identidade do cliente. Em homologação, inspecione os cabeçalhos recebidos pelo backend através da rota HTTP após atualizar. Valores fornecidos pelo cliente não devem ser aceitos como comprovação de um certificado validado pelo proxy.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v3
>= v3.7.0, <= v3.7.13
v3.7.14
O suporte à anotação auth-tls-pass-certificate-to-upstream foi introduzido em v3.7.0. O cenário descrito exige que a rota HTTP alcance o backend, em vez de apenas redirecionar para HTTPS.
Gravidade altaCVSS: 7,0/10Correção disponível
Pré-autenticação Negotiate deixa uma conexão autenticada no pool compartilhado
A primeira requisição de uma nova conexão de cliente utiliza o transporte compartilhado. O Traefik só prepara o isolamento após observar um desafio NTLM ou Negotiate do backend. Quando um cliente envia um token Negotiate válido já nessa primeira requisição, o backend autentica a conexão e responde com sucesso. A conexão autenticada permanece no pool compartilhado e pode ser reutilizada por outro cliente sem credenciais, que recebe as permissões da identidade anterior.
Casos de uso afetados
Você mantém um backend com autenticação NTLM ou Negotiate vinculada à conexão e reutilização de conexões habilitada.
Um cliente legítimo envia Authorization: Negotiate na primeira requisição, sem aguardar o desafio 401, por uma conexão HTTP/1.1 ou HTTP/2.
Confira na sua instância
Confira no comportamento dos clientes se o cabeçalho Authorization: Negotiate é enviado antes de qualquer resposta 401. Relacione esse comportamento aos backends que reutilizam conexões autenticadas. Depois da atualização, faça uma conferência em homologação com uma conta de teste pré-autenticada e outra conexão independente sem credenciais. A segunda conexão não deve herdar a identidade da primeira.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v2
>= v2.11.0, <= v2.11.57
v2.11.58
github.com/traefik/traefik/v3
>= v3.0.0, <= v3.7.13
v3.7.14
O fluxo normal que aguarda o desafio 401 não é afetado por este aviso. A falha é distinta do GHSA-qqjf-53cj-pwvv, relacionado ao transporte HTTP/3. As linhas v3.0 a v3.6 precisam migrar para v3.7.14.
Gravidade altaCVSS: 7,0/10Correção disponível
Rota HTTP de ssl-passthrough ignora os controles de acesso do Ingress
Na versão v3.7.13, o provedor Kubernetes Ingress NGINX cria uma rota HTTP adicional para o Ingress com ssl-passthrough habilitado. Essa rota é construída fora do processamento habitual das anotações, por isso não recebe os middlewares de autenticação e de restrição por origem. Um cliente que alcança o entry point HTTP com o host correspondente consegue chegar ao backend sem cumprir os controles declarados no Ingress.
Casos de uso afetados
Você executa v3.7.13 com nginx.ingress.kubernetes.io/ssl-passthrough: "true" e mantém um entry point HTTP acessível.
O mesmo Ingress declara auth-type com auth-secret, auth-url ou whitelist-source-range para restringir o acesso ao backend.
Confira na sua instância
Localize os Ingresses com ssl-passthrough habilitado e examine os roteadores gerados nos entry points sem TLS. Confira se os middlewares correspondentes às anotações de acesso estão associados a essas rotas. Em homologação, após atualizar, valide que o acesso HTTP sem autenticação ou a partir de uma origem não permitida é recusado conforme a configuração.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v3
>= v3.7.13, <= v3.7.13
v3.7.14
A correção altera os nomes dos roteadores HTTP gerados para esse cenário. Confira as referências a esses nomes na migração. O Traefik v2 e as versões v3 anteriores a v3.7.13 não são afetados.
Gravidade altaCVSS: 7,0/10Correção disponível
Nomes semelhantes de Secrets podem trocar a autoridade certificadora de um host
O provedor Kubernetes Ingress NGINX substitui pontos por hífens ao gerar o nome da opção TLS a partir do Secret indicado em auth-tls-secret. Nomes como my.secret e my-secret podem produzir a mesma identificação. O Ingress processado depois reutiliza a opção do primeiro e seu host pode aceitar certificados emitidos pela autoridade certificadora de outro host, enquanto recusa certificados dos próprios clientes.
Casos de uso afetados
Você configura autenticação por certificado de cliente com nginx.ingress.kubernetes.io/auth-tls-secret e mantém Secrets cujos nomes ou namespaces colidem após a troca de pontos por hífens.
Nas versões v3.7.0 a v3.7.10, os nomes dos Ingresses também participam da identificação gerada e podem causar a mesma colisão.
Confira na sua instância
Compare os nomes e namespaces dos Secrets referenciados por auth-tls-secret, observando pares que diferem apenas por ponto e hífen. Nas versões v3.7.0 a v3.7.10, inclua os nomes dos Ingresses nessa conferência. Após atualizar, confira as opções TLS geradas e teste cada host com certificados de homologação emitidos por sua autoridade autorizada e pela autoridade do outro host. Somente a cadeia autorizada para aquele destino deve ser aceita.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v3
>= v3.7.0, <= v3.7.13
v3.7.14
A correção preserva os nomes dos recursos na identificação gerada. O Traefik v2 e as versões v3 anteriores a v3.7.0 não são afetados, pois ainda não oferecem esse suporte à anotação auth-tls-secret.
Gravidade moderadaCVSS: 6,9/10Correção disponível
Host negado pode remover a exigência de certificado de cliente
O Traefik inclui indevidamente o domínio de um matcher Host negado na relação de domínios atendidos pelo roteador. Quando outro roteador atende esse domínio com opções TLS diferentes, surge um conflito e o Traefik recorre às opções default. Se elas não exigirem certificado de cliente, o backend configurado com RequireAndVerifyClientCert pode aceitar uma conexão sem essa autenticação.
Casos de uso afetados
Você mantém um roteador com !Host para excluir um domínio e outro roteador atende esse mesmo domínio com autenticação por certificado de cliente.
As opções TLS default não exigem certificado, enquanto o domínio excluído utiliza uma configuração própria com RequireAndVerifyClientCert.
Confira na sua instância
Localize os matchers !Host nas configurações dos roteadores e compare os domínios excluídos com aqueles que usam tls.options próprias. Procure mensagens de conflito TLS no nível ERROR. Em homologação, confirme que o domínio protegido recusa o acesso sem certificado e continua aceitando o certificado autorizado.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v2
<= v2.11.57
v2.11.58
github.com/traefik/traefik/v3
>= v3.0.0, <= v3.7.12
v3.7.13
O aviso indica core.strictTLSOptions=true como mitigação porque desativa o retorno às opções default diante do conflito. As versões v3 anteriores à linha v3.7 também são afetadas e precisam migrar para uma versão mantida e corrigida.
Gravidade moderadaCVSS: 6,3/10Correção disponível
Requisições simultâneas podem interromper a autenticação e o Traefik
O transporte dedicado à autenticação NTLM ou Negotiate era lido e alterado sem sincronização. Como HTTP/2 e HTTP/3 permitem várias requisições simultâneas na mesma conexão, duas delas podem disputar esse transporte e substituir uma referência ainda em uso. Isso pode abandonar conexões com o backend e interromper a autenticação do cliente. Uma leitura inconsistente da referência também pode encerrar o processo do Traefik.
Casos de uso afetados
Seus backends emitem desafios NTLM ou Negotiate e recebem requisições por conexões HTTP/2 ou HTTP/3 com múltiplos streams.
Uma aplicação realiza chamadas concorrentes pela mesma conexão enquanto o Traefik estabelece o transporte dedicado à autenticação.
Confira na sua instância
Identifique os backends com autenticação vinculada à conexão e confira os protocolos usados pelos clientes. Procure reinícios do processo e falhas de autenticação associados a requisições simultâneas. Após atualizar, execute uma carga controlada em homologação com múltiplos streams e acompanhe a continuidade da autenticação e a estabilidade do processo.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
github.com/traefik/traefik/v2
>= v2.11.0, <= v2.11.57
v2.11.58
github.com/traefik/traefik/v3
>= v3.0.0, <= v3.7.13
v3.7.14
A correção sincroniza o acesso com um mutex e preserva o transporte já associado à conexão. A mesma alteração trata o isolamento por ServersTransport descrito separadamente no GHSA-cw35-4q88-3rmp.
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.
