A mais grave permite passar pelo digestAuth com qualquer nome de usuário e sem senha, porque um usuário inexistente recebe segredo vazio. As outras três envolvem conflito de opções TLS em rotas multi-host, Ingresses no mesmo host e o limite crossProviderNamespaces. As correções estão em 2.11.55 e 3.7.11.
Aplicativo
Traefik
Data do compilado
Vulnerabilidades
4
A correção do digestAuth troca a biblioteca de digest fixada, que recusa usuário desconhecido. A mitigação do conflito de TLS exige ativar core.strictTLSOptions, que vem desligado por padrão. A falha de crossProviderNamespaces foi reportada como média, mas recebeu classificação alta na fonte. 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
digestAuth aceita qualquer usuário e nenhuma senha
O middleware digestAuth usa um provedor de segredo que devolve string vazia para um nome de usuário ausente da lista configurada, em vez de indicar que o usuário não existe. A biblioteca de digest fixada aceita essa string vazia como HA1 e segue com a verificação criptográfica normal. Todos os outros valores do cálculo são escolhidos pelo cliente ou entregues no desafio 401, então o digest esperado fica totalmente calculável. Qualquer cliente remoto sem autenticação passa pela verificação com um nome arbitrário e sem senha em duas requisições, em qualquer rota protegida por digestAuth, inclusive o dashboard e a API do Traefik. Com headerField configurado, o nome escolhido pelo atacante é enviado ao backend, que pode ser induzido a aceitar um usuário administrativo.
Casos de uso afetados
Você protege o dashboard ou a API do Traefik com digestAuth. Um cliente sem credenciais acessa a configuração dinâmica, que inclui hashes de outros middlewares e chaves privadas embutidas.
Você usa digestAuth com headerField para repassar a identidade a um backend. O atacante escolhe o valor do cabeçalho e pode ser tratado como administrador pela aplicação.
Você usa o log de acesso para auditar acessos. O nome forjado é gravado como usuário autenticado e atribui a intrusão a uma identidade inventada.
Confira na sua instância
Procure rotas com o middleware digestAuth e confirme a versão do Traefik. No log de acesso, compare o campo authuser com os usuários realmente configurados e investigue nomes que não constam na lista. Em ambiente de teste, envie duas requisições a uma rota protegida, uma para obter o desafio e outra com um usuário inexistente e o digest calculado a partir do HA1 vazio. Depois de atualizar para 2.11.55 ou 3.7.11, confirme que a segunda requisição recebe 401.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.x
<= v2.11.54
v2.11.55
3.x
>= v3.0.0, <= v3.7.10
v3.7.11
Todas as versões 1, 2 e 3 que trazem o middleware são afetadas em qualquer configuração, inclusive a padrão. A força das senhas configuradas não altera o resultado, porque o ataque não usa um usuário configurado. Enquanto a atualização não acontece, troque digestAuth por basicAuth ou por autenticação no backend.
Gravidade altaCorreção disponível
Conflito de opções TLS em rota multi-host remove o certificado de cliente do host protegido
As opções de TLS são aplicadas no handshake e associadas aos nomes de host da rota, não à rota. Quando várias rotas no mesmo entrypoint atendem o mesmo host com opções diferentes, o Traefik resolve o conflito voltando às opções default. Em uma rota com vários hosts, essa volta vale para todos os nomes da rota, inclusive os que não estavam em conflito. Uma rota que exige certificado de cliente para um dos hosts deixa de exigir assim que outra rota cria conflito de opções em qualquer outro host da mesma rota. Um cliente sem certificado conclui o handshake do host protegido e alcança o backend. A correção adiciona core.strictTLSOptions, que desativa a volta ao padrão e marca as rotas em conflito como erro, mas fica desligada por padrão.
Casos de uso afetados
Você tem uma rota com Host(`admin.example.com`, `public.example.com`) e opções TLS que exigem certificado de cliente. Outra rota para public.example.com com opções padrão remove a exigência também de admin.example.com.
Você separa hosts administrativos e públicos na mesma rota para simplificar a configuração. Um conflito em qualquer host da rota atinge os demais.
Confira na sua instância
Liste as rotas com mais de um host e opções TLS não padrão. Procure outra rota que atenda um desses hosts com opções diferentes e confira o log em nível DEBUG para a mensagem de host servido por várias rotas com opções TLS distintas. Acesse o host protegido sem certificado de cliente e observe o resultado. Depois de atualizar para 2.11.55 ou 3.7.11, ative core.strictTLSOptions e confirme que a rota em conflito é marcada como erro e que o host protegido exige o certificado.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
2.x
<= v2.11.54
v2.11.55
3.x
>= v3.0.0, <= v3.7.10
v3.7.11
A falha depende de uma rota multi-host que sobreponha outra rota com opção TLS diferente em apenas um dos hosts. Rotas de um host só não acionam esse caminho. Separar os hosts em rotas distintas evita o conflito enquanto você prepara a atualização, e core.strictTLSOptions impede a volta ao padrão.
Gravidade altaCorreção disponível
Dois Ingresses no mesmo host desativam a exigência de certificado de cliente
No provedor Kubernetes Ingress NGINX, a opção TLS criada para um Ingress com a anotação nginx.ingress.kubernetes.io/auth-tls-secret recebia o nome do namespace e do Ingress. Dois Ingresses no mesmo host, com o mesmo segredo de CA de cliente e o mesmo modo de autenticação, geravam duas opções TLS distintas para o mesmo host. O Traefik trata isso como conflito e volta à configuração padrão do entrypoint, que não solicita certificado de cliente. Uma rota com auth-tls-verify-client igual a on fica acessível sem certificado. A correção deriva o nome da opção apenas do segredo de CA e do modo de autenticação, de modo que Ingresses com a mesma política de mTLS usem uma única opção.
Casos de uso afetados
Você divide o mesmo host em dois Ingresses, um para /protected e outro para /second, ambos com auth-tls-secret e auth-tls-verify-client on. Um cliente sem certificado alcança as duas rotas.
Você permite que outro locatário crie um Ingress adicional para um host existente. O novo objeto introduz o conflito e remove a exigência de certificado do host.
Confira na sua instância
Agrupe os Ingresses HTTPS por host e conte quantos usam auth-tls-secret e auth-tls-verify-client. Procure nomes de opção TLS diferentes para o mesmo host no log em nível DEBUG. Acesse a rota protegida sem certificado de cliente e observe o resultado. Depois de atualizar para 3.7.11, repita o acesso e confirme que o handshake falha sem certificado e que um certificado válido da CA configurada é aceito.
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.10
v3.7.11
O tratamento de autenticação de cliente no provedor entrou em 3.7.0, então o Traefik 2 e versões 3 até 3.6 não carregam esse caminho. A falha depende de mais de um Ingress para o mesmo host. Enquanto a atualização não acontece, unifique a configuração de TLS desses Ingresses ou ative core.strictTLSOptions.
Gravidade altaCorreção disponível
Anotação service.middlewares ignora a lista crossProviderNamespaces
O provedor Kubernetes Ingress aplica a lista providers.kubernetesIngress.crossProviderNamespaces para as anotações router.middlewares e service.serverstransport, mas não para a anotação traefik.ingress.kubernetes.io/service.middlewares do Service. O valor era copiado para o serviço dinâmico sem conferir o namespace do Service. Um locatário restrito a um namespace fora da lista pode anexar ao próprio Service um middleware mantido por outro provedor e conhecido pelo nome qualificado. Quando esse middleware injeta uma credencial no backend, o locatário recupera a credencial em um backend que controla, sem acesso à configuração do operador nem aos segredos do Kubernetes.
Casos de uso afetados
Você mantém um middleware de operador que injeta uma chave de API em serviços internos e limita crossProviderNamespaces. Um locatário fora da lista anexa esse middleware ao próprio Service e recebe a chave.
Você usa namespaces separados por locatário e espera que a lista impeça referências entre provedores. A anotação do Service não passa pela mesma checagem das demais.
Confira na sua instância
Confira o valor de crossProviderNamespaces e liste os namespaces autorizados. Procure Services com a anotação traefik.ingress.kubernetes.io/service.middlewares apontando para nomes com @. Verifique se o namespace do Service está na lista permitida. Em ambiente de teste, anexe um middleware de outro provedor a um Service de um namespace excluído e observe se a requisição recebe o cabeçalho injetado. Depois de atualizar para 3.7.11, repita o teste e confirme que a referência é recusada.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
3.7.x
>= v3.7.1, <= v3.7.10
v3.7.11
A opção crossProviderNamespaces entrou em 3.7.1, então o Traefik 2 e versões 3 até 3.6 não têm esse controle. O relator propôs classificação média; a fonte publica a falha como alta. A exploração exige privilégio baixo no namespace e o nome qualificado de um middleware sensível já existente.
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.
