Traefik 2.11.52 / 3.6.23 / 3.7.7 : contournement d'auth ReplacePathRegex (CERTFR-2026-AVI-0851)

Le CERT-FR a publié le 9 juillet 2026 l'avis CERTFR-2026-AVI-0851 qui répercute le palier Traefik du même jour. Trois avis GitHub distincts sont adressés dans les versions 2.11.52, 3.6.23 et 3.7.7. La faille la plus notable — GHSA-cxjq-mrr5-89rv, CVSS 7,8 — est un contournement d'authentification dans le middleware ReplacePathRegex : une requête forgée passe la protection appliquée au niveau route et atterrit, une fois le chemin normalisé côté backend, sur une ressource privée. Aucun identifiant CVE n'est encore assigné aux trois avis à la date de publication.

Versions concernées

D'après le palier Traefik 3.7.7 et l'avis CERT-FR :

• Traefik antérieures à 2.11.52
• Traefik 3.6.x antérieures à 3.6.23
• Traefik 3.7.x antérieures à 3.7.7

Les trois branches supportées sont concernées. Les images Docker officielles (traefik:2.11, traefik:3.6, traefik:3.7, traefik:latest) sont republiées à partir du palier ; toute image reconstruite ou reprise depuis un cache antérieur reste vulnérable jusqu'au docker pull explicit.

GHSA-cxjq-mrr5-89rv — contournement d'auth ReplacePathRegex (CVSS 7,8)

L'avis GHSA-cxjq-mrr5-89rv décrit une variante de la classe path-normalization auth bypass : le middleware ReplacePathRegex réécrit le chemin d'une requête en appliquant une expression régulière. Quand la regex capture un segment contrôlé par l'utilisateur sans exiger de séparateur strict — l'exemple canonique étant regex: "^/api(.*)" avec replacement: "/$1" — un attaquant peut soumettre une requête dont le chemin réécrit contient .. non normalisé, par exemple /../admin.

Traefik transmet ce chemin non normalisé au backend. Les serveurs applicatifs normalisent alors la séquence — c'est le comportement standard côté HTTP/1.1 — et la requête aboutit sur /admin, une route qu'un routeur authentifié séparé était censé protéger. La conséquence : un accès non authentifié à des chemins protégés au niveau routeur, dès que ReplacePathRegex est utilisé sur une route publique dans la même configuration.

Le patch, appliqué dans le PR #13466, assainit le chemin remplacé avant de le passer plus loin dans la chaîne. Les vecteurs de compensation historique — ajouter un StripPrefix derrière, valider en amont côté opérateur — ne suffisent pas : la valeur qui atteint le backend est celle produite par le remplacement, pas celle vue par les middlewares suivants.

GHSA-42cj-m3vj-89wv — allowlist crossProviderNamespaces non appliquée en TCP (CVSS 5,3)

L'avis GHSA-42cj-m3vj-89wv concerne le provider Kubernetes CRD. Le paramètre crossProviderNamespaces, qui contraint les références inter-provider (typiquement pour empêcher qu'une ressource dans un namespace non privilégié référence un serversTransport@file opérateur), était correctement appliqué pour les IngressRoute HTTP mais pas pour les IngressRouteTCP.spec.services[].serversTransport.

Résultat : un auteur de route TCP disposant de droits limités dans un namespace hors allowlist pouvait référencer un serversTransport: <nom>@file privilégié — c'est-à-dire hériter d'un certificat client mTLS backend, d'une identité SPIFFE, ou d'un réglage PROXY-protocol appartenant à l'opérateur — sans autorisation additionnelle. Le correctif étend la vérification crossProviderNamespaces au chemin TCP. CVSS 5,3.

GHSA-qq9q-x9w4-chhj — confusion de namespace Gateway API (CVSS 5,3)

L'avis GHSA-qq9q-x9w4-chhj est spécifique au provider Kubernetes Gateway API, ne concernant donc que la branche 3.7.x (< 3.7.7). Lorsqu'une HTTPRoute référence, dans spec.rules[].backendRefs[].filters[].extensionRef, un Middleware Traefik, la résolution utilise le namespace du backend Service au lieu du namespace de la HTTPRoute.

Un auteur de route peu privilégié qui dispose d'un ReferenceGrant autorisant la référence d'un Service dans un autre namespace peut donc, sans autre autorisation, lier un Middleware Traefik du namespace backend à sa route. Si ce Middleware injecte des en-têtes d'identité de type reverse-proxy, l'application aval reçoit alors une identité authentifiée sous contrôle attaquant. CVSS 5,3.

Statut d'exploitation

Aucune exploitation active n'est mentionnée par l'avis CERT-FR ni par les trois GHSA. Aucun PoC public à la publication. Le patch pour GHSA-cxjq-mrr5-89rv est cependant lisible dans le PR #13466, donc la fenêtre patch-diff est ouverte : la logique de la normalisation .. post-remplacement est explicite dans le commit, et une charge de test tient en une requête curl.

Que faire

1. Passer sur 2.11.52, 3.6.23 ou 3.7.7 selon la branche en production. Les notes de release recensent les trois paliers. Pour un déploiement Docker, docker pull traefik:<tag> puis restart ; pour Helm, helm upgrade avec la version d'image bumpée dans les values.
2. Auditer l'usage de ReplacePathRegex dans les StaticConfig et DynamicConfig. Toute configuration où la regex capture un segment sans terminateur strict est susceptible du bypass. Le pire cas : un ReplacePathRegex sur un routeur public qui masque un routeur authentifié partageant le même PathPrefix racine. Compenser temporairement — le temps de bouger la version — en restreignant la regex à des séparateurs explicites (^/api/([^/]+)/(.*)$ plutôt que ^/api(.*)).
3. Sur clusters Kubernetes CRD, vérifier les IngressRouteTCP qui référencent un serversTransport@file. Les namespaces qui ont accès à créer des IngressRouteTCP mais qui ne sont pas dans crossProviderNamespaces avaient jusqu'ici un accès non prévu à ces transports. Auditer les journaux serversTransport avant mise à jour.
4. Sur clusters Gateway API (branche 3.7.x uniquement), énumérer les HTTPRoute qui utilisent un ExtensionRef vers un Middleware Traefik dans un namespace différent, et vérifier que ces liaisons croisées correspondent à ce que l'opérateur a explicitement autorisé — pas seulement à ce qu'un ReferenceGrant de Service permet.
5. Suivi NIS2 : l'avis CERTFR-2026-AVI-0851 est la référence à consigner dans le suivi du délai de traitement pour les entités régulées qui exposent un ingress Traefik en frontal.

Contexte

C'est le troisième contournement d'authentification sur les middlewares de path-manipulation de Traefik en un trimestre. En avril, CVE-2026-40912 frappait StripPrefixRegex avec un désynchro entre Path et RawPath percent-encodés. En mai, CVE-2026-48020 frappait StripPrefix via un .. traversal résolu après normalisation backend. Aujourd'hui, ReplacePathRegex répète le schéma une troisième fois — la même racine (traitement du chemin en amont, normalisation en aval, absence d'un contrat strict entre les deux) et le même impact opérationnel (routeur public qui débloque un routeur authentifié). Deux avis CERT-FR étaient déjà consacrés à Traefik en 2026 avant celui-ci (AVI-0154, AVI-0823).

La leçon structurelle pour un opérateur qui pilote sa passerelle Traefik en frontal : ne pas faire du middleware de path-manipulation la seule ligne de défense. La règle d'or reste — router les routes privées derrière un routeur qui ne partage pas de préfixe public, appliquer l'authentification côté backend en défense en profondeur, et ne pas construire d'ACL sur la seule base d'une regex de chemin réécrite en amont.