Traefik vient de corriger une faille jugée High dans son middleware ForwardAuth : dans certaines configurations, l’identité d’un utilisateur authentifié pouvait fuiter vers un autre client qui, lui, ne l’était pas. Le problème porte l’identifiant GHSA-hrpp-p4fc-wwf8, publié le 21 octobre 2026 par le mainteneur mmatur dans l’advisory GitHub officielle du projet. Aucun CVE n’a été attribué à cette faille — seul ce GHSA ID la documente pour l’instant.
L’advisory classe la vulnérabilité en sévérité High, avec un score CVSS v4 de base de 7.0 (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). Elle touche le module Go traefik/traefik : en v2, toutes les versions jusqu’à la 2.11.59 incluse ; en v3, de la 3.0.0 à la 3.7.15. Les correctifs sont sortis en v2.11.60 et v3.7.16.
Comment la fuite se produit via ForwardAuth
Le middleware ForwardAuth envoie une sous-requête à un serveur d’authentification externe avant de laisser passer la requête d’origine. Le hic : ces sous-requêtes transitent par un pool de connexions partagé entre tous les clients de Traefik, plutôt que par une connexion isolée pour chacun.
Tant que le serveur d’authentification utilise un schéma sans état, où chaque sous-requête porte ses propres identifiants, ce partage ne change rien. Le problème apparaît quand ce serveur repose plutôt sur un schéma lié à la connexion elle-même, comme NTLM ou SPNEGO/Kerberos Negotiate. Ces deux mécanismes se négocient une seule fois par connexion TCP, puis restent valides pour toutes les requêtes suivantes sur cette connexion — c’est d’ailleurs typiquement comme ça qu’IIS Windows Authentication fonctionne.
Résultat : Traefik peut réutiliser une connexion du pool déjà authentifiée pour un utilisateur, et un client totalement différent — non authentifié, arrivé sur une connexion frontend distincte — voit sa propre sous-requête ForwardAuth traitée sur cette même connexion déjà validée. Le serveur d’authentification répond comme s’il parlait toujours au premier utilisateur, et Traefik transmet cette identité au backend via authResponseHeaders. Concrètement, un second client peut atterrir sur le backend protégé sous l’identité du premier, sans jamais présenter ses propres identifiants.
Il existe une seconde variante, propre à Traefik v3.7 : le même pool partagé affecte aussi les appels d’authentification faits pour l’annotation auth-url du fournisseur Kubernetes Ingress NGINX. Le correctif en v3.7.16 étend à ces requêtes l’isolation par connexion frontend qu’un patch précédent avait déjà posée côté proxy backend.
Qui doit agir
Cette faille ne joue que si ForwardAuth est couplé à un backend d’authentification lié à la connexion. Une instance Traefik qui s’appuie sur OAuth2, Authelia, Authentik ou tout autre schéma authentifiant chaque requête indépendamment n’est pas concernée. NTLM et Kerberos Negotiate se croisent surtout en entreprise, devant IIS ou des services intégrés à Active Directory — on les voit rarement dans un homelab self-hosted. La plupart des installations qui utilisent Traefik comme simple reverse proxy à base de labels Docker devant Jellyfin, Immich ou Nextcloud ne devraient pas être exposées par ce chemin précis.
Ça n’empêche pas de mettre à jour : ça ne coûte rien et ferme la porte, exploitable ou pas dans votre cas. À faire :
- Vérifier la version installée avec
traefik versionou en regardant le tag de l’image Docker, et confirmer qu’elle est au moins en v2.11.60 ou v3.7.16. - Récupérer l’image à jour (
traefik:v2.11.60,traefik:v3.7.16, outraefik:latestune fois celle-ci basculée) et redéployer. - Regarder si un middleware ForwardAuth de la configuration pointe vers un serveur d’authentification en NTLM ou Negotiate — c’est la seule configuration réellement touchée par cette advisory.
- Ne pas oublier que les versions v3.0 à v3.6 sont en fin de vie et ne recevront pas de rétroportage : qui tourne encore là-dessus doit migrer vers v2.11.60 ou v3.7.16 plutôt que d’attendre un correctif ponctuel.
Pour configurer Traefik en reverse proxy devant des services self-hosted, middleware ForwardAuth compris, la fiche Traefik de SelfHostLab détaille la mise en place. Pour le détail technique complet — vecteur CVSS, analyse du mainteneur — direction l’advisory GitHub officielle GHSA-hrpp-p4fc-wwf8.