Skip to content
Hacker Posts

Traefik : contournement d'authentification ForwardAuth (CVSS 7.0)

Un défaut du middleware ForwardAuth de Traefik avec les schémas NTLM/Negotiate permet d'être authentifié comme un autre utilisateur. Corrigé en 3.7.16 et 2.11.60 (CERTFR-2026-AVI-1356).

Publié le 3 min de lecture
traefikalertecert-frreverse-proxykubernetes

Le reverse-proxy Traefik corrige une vulnérabilité d'authentification de gravité haute (CVSS v4 7.0) dans son middleware ForwardAuth. L'avis éditeur GHSA-hrpp-p4fc-wwf8 est la source primaire ; le CERT-FR l'a relayé le 21 octobre sous CERTFR-2026-AVI-1356. Aucune CVE n'a été assignée à ce jour. Si vous utilisez ForwardAuth avec une authentification liée à la connexion (NTLM ou SPNEGO/Kerberos Negotiate), mettez à jour.

Versions concernées

D'après l'avis GitHub :

  • Traefik v2 : versions 2.11.59 et antérieures → corrigé en 2.11.60
  • Traefik v3 : 3.0.0 à 3.7.15 → corrigé en 3.7.16
  • Les branches 3.0 à 3.6 sont en fin de vie et ne recevront pas de correctif dédié : il faut migrer vers 3.7.16.

Ce que fait la faille

ForwardAuth émet ses sous-requêtes d'authentification via un pool de connexions partagé entre tous les clients. Quand le serveur d'authentification utilise un schéma lié à la connexion (NTLM, ou Negotiate/Kerberos — par exemple l'authentification Windows d'IIS), une connexion déjà authentifiée peut être réutilisée pour la sous-requête d'un autre client. Ce client reçoit alors une réponse d'authentification réussie portant l'identité de la victime.

Traefik transmet ensuite cette identité au backend via authResponseHeaders : un client non authentifié, sur une connexion frontale distincte, accède au backend en tant qu'un autre utilisateur. En v3.7, le même défaut s'applique aux requêtes d'authentification externes issues de l'annotation auth-url de Kubernetes Ingress NGINX.

Le vecteur CVSS v4 publié est CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N : aucun impact sur Traefik lui-même, mais confidentialité et intégrité élevées sur les systèmes en aval, sans privilège ni interaction requis. La condition AT:P reflète la configuration nécessaire — un schéma d'auth lié à la connexion.

Conditions d'exploitation

  • Le serveur d'authentification derrière ForwardAuth utilise NTLM ou Negotiate.
  • L'attaquant atteint le middleware via une connexion frontale séparée.
  • Une connexion authentifiée d'une victime existe dans le pool partagé.

Que faire

  1. Mettez à jour vers Traefik 3.7.16 ou 2.11.60 ; depuis une branche 3.0–3.6, migrez directement en 3.7.16.
  2. Identifiez les middlewares ForwardAuth dont le serveur d'authentification repose sur NTLM ou Kerberos Negotiate — ce sont les seuls configurations exposées.
  3. En Kubernetes, vérifiez les ingress utilisant l'annotation auth-url (compatibilité Ingress NGINX) en v3.7.
  4. En attendant la mise à jour, basculez si possible le serveur d'authentification vers un schéma non lié à la connexion (jeton Bearer, en-tête par requête), qui n'est pas affecté.

Contexte

Le bug ne vient pas du schéma d'authentification mais de l'hypothèse qu'une connexion HTTP réutilisée est anonyme — fausse dès que l'auth est négociée au niveau de la connexion TCP. C'est un classique des proxies qui mutualisent un pool en amont d'un backend stateful. Traefik étant un ingress courant devant des applications internes sous authentification Windows, la population concernée est réduite mais sensible : l'impact est un accès backend sous une identité volée, sans trace côté proxy.

Articles liés