L’essentiel à retenir

Une vulnérabilité a été publiée le 16 juillet 2026 dans le provider Kubernetes Ingress NGINX de Traefik.

Elle affecte :

Traefik 3.7.0 à 3.7.7 inclus

La version corrigée est :

Traefik 3.7.8

Le bulletin GitHub classe actuellement la vulnérabilité avec une sévérité élevée et un score CVSS v4 de 7,8.

Aucun identifiant CVE n’était encore attribué au moment de la dernière vérification de cet article.

Le scénario publié peut permettre à un attaquant non authentifié de contourner une authentification ou une autorisation appliquée uniquement sur une route protégée.

Il ne concerne pas automatiquement toutes les installations de Traefik. Plusieurs conditions doivent être réunies :

  1. le provider Kubernetes Ingress NGINX est activé ;
  2. un Ingress public utilise l’annotation rewrite-target ;
  3. la route utilise une expression régulière pouvant capturer une séquence de traversée de chemin ;
  4. une autre route du même backend protège un chemin distinct ;
  5. le backend normalise les segments . et .. avant de traiter la requête.

Quel est le rôle de Traefik ?

Traefik est un reverse proxy et un contrôleur d’entrée pouvant recevoir les connexions destinées à plusieurs applications.

Il peut notamment :

  • écouter sur les ports HTTP et HTTPS ;
  • sélectionner une application selon le nom de domaine ;
  • router une requête selon son chemin ;
  • terminer une connexion TLS ;
  • appliquer une authentification ;
  • filtrer des adresses IP ;
  • modifier des en-têtes ;
  • réécrire un chemin ;
  • découvrir automatiquement des services Docker ou Kubernetes.

Dans une architecture Kubernetes, une requête peut suivre ce parcours :

Internet
   │
   ▼
Traefik
   │
   ├── Route publique /api
   │
   └── Route protégée /admin
             │
             ▼
        Authentification
             │
             ▼
          Backend

Traefik décide d’abord quelle route doit traiter la requête. Il exécute ensuite les middlewares associés à cette route.

Cette chronologie est au cœur de la vulnérabilité.

Quel composant est réellement affecté ?

Le bulletin vise précisément le provider :

Kubernetes Ingress NGINX

Ce provider permet à Traefik d’interpréter des objets Kubernetes et des annotations conçus pour l’écosystème Ingress NGINX.

Le composant concerné traite notamment l’annotation :

nginx.ingress.kubernetes.io/rewrite-target

La vulnérabilité ne doit donc pas être présentée comme affectant indistinctement :

  • toutes les installations Docker ;
  • tous les providers Traefik ;
  • toutes les versions 2.x ;
  • toutes les branches 3.x ;
  • toutes les règles de réécriture.

Le bulletin confirme que :

  • les versions 3.7.0 à 3.7.7 contiennent l’implémentation vulnérable ;
  • les branches 2.11 et 3.6 ne contiennent pas cette implémentation précise ;
  • la correction est disponible dans la version 3.7.8.

Comprendre la vulnérabilité

Une réécriture effectuée après le choix de la route

Prenons une architecture simplifiée :

  • une route publique envoie /api vers une application ;
  • une route distincte protège /admin avec une authentification ;
  • les deux routes pointent vers le même backend ;
  • la route publique réécrit le chemin reçu.

Traefik sélectionne initialement la route publique à partir du chemin présenté par le client.

Le middleware de réécriture modifie ensuite ce chemin.

Dans le cas vulnérable, la réécriture peut créer une séquence contenant un segment parent, par exemple :

/../admin

Le backend normalise ensuite ce chemin et le transforme en :

/admin

La requête atteint alors le contenu administratif sans repasser par la route sur laquelle l’authentification avait été configurée.

Pourquoi l’authentification peut-elle être contournée ?

L’authentification est associée à la route protégée.

Mais cette route n’est jamais sélectionnée : la requête a d’abord été acceptée par la route publique.

La transformation dangereuse intervient ensuite.

On obtient donc la séquence suivante :

Chemin reçu
    │
    ▼
Sélection de la route publique
    │
    ▼
Réécriture du chemin
    │
    ▼
Normalisation par le backend
    │
    ▼
Accès à un chemin normalement protégé

Le routeur ne recommence pas sa sélection après la réécriture.

Pourquoi sanitizePath=true ne suffit-il pas ?

Traefik peut normaliser les chemins à l’entrée.

Cette protection intervient cependant avant la sélection de la route et avant l’exécution du middleware vulnérable.

Le chemin dangereux est créé après cette première étape.

Le bulletin précise donc que la valeur suivante ne constitue pas, à elle seule, une mesure de protection suffisante :

sanitizePath: true

Quelles protections peuvent être contournées ?

Le bulletin officiel mentionne un risque de contournement de contrôles appliqués uniquement à la route protégée, notamment :

  • BasicAuth ;
  • DigestAuth ;
  • ForwardAuth ;
  • certaines restrictions par adresse IP ;
  • d’autres contrôles d’accès attachés exclusivement au routeur protégé.

L’impact réel dépend du chemin atteint.

Il peut s’agir :

  • d’informations administratives ;
  • de données sensibles ;
  • d’une interface de gestion ;
  • d’une API permettant des modifications ;
  • d’une action acceptant des méthodes POST, PUT, PATCH ou DELETE.

La vulnérabilité n’est donc pas limitée à la lecture de contenu.

Les conditions nécessaires à l’exploitation

Le scénario documenté exige la combinaison de plusieurs éléments.

Le provider Kubernetes Ingress NGINX est actif

La configuration statique peut prendre différentes formes.

Exemple en YAML :

providers:
  kubernetesIngressNginx: {}

Exemple en ligne de commande :

--providers.kubernetesIngressNginx

Le nom exact des options peut varier selon la configuration utilisée. Consultez les arguments du conteneur et la documentation correspondant à votre version.

Un Ingress public utilise une réécriture par expression régulière

Les annotations concernées comprennent notamment :

nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: "/..."

La présence de ces annotations ne prouve pas que la route est exploitable. Elle indique qu’un examen est nécessaire.

L’expression ne force pas une séparation correcte

Le problème apparaît lorsque l’expression régulière peut capturer des données contrôlées par le client juste après le préfixe attendu, sans exiger :

  • un séparateur / ;
  • ou la fin du chemin.

Une règle trop permissive peut alors accepter un chemin qui ressemble à la route publique tout en capturant une séquence utilisée pour remonter dans l’arborescence.

Une route protégée pointe vers le même backend

L’impact devient significatif lorsqu’un chemin sensible existe sur le même service, mais dépend d’une autre route Traefik pour son authentification.

Le backend normalise le chemin

Le serveur ou framework placé derrière Traefik doit interpréter les segments parents et transformer le chemin réécrit avant de sélectionner sa ressource.

Le comportement dépend :

  • du serveur HTTP ;
  • du framework ;
  • de l’application ;
  • d’un éventuel second proxy ;
  • de la manière dont le backend traite le chemin brut.

Étape 1 : identifier la version installée

Déploiement Docker

Listez les conteneurs et les images :

docker ps \
  --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' |
  grep -i traefik

Affichez l’image exacte d’un conteneur :

docker inspect \
  --format '{{.Config.Image}}' \
  NOM_DU_CONTENEUR

Essayez d’afficher la version du binaire :

docker exec NOM_DU_CONTENEUR traefik version

La commande peut varier si :

  • le conteneur porte un autre nom ;
  • le binaire n’est pas présent dans le chemin attendu ;
  • l’image utilise un point d’entrée personnalisé.

Déploiement Kubernetes

Recherchez les déploiements associés à Traefik :

kubectl get deployments --all-namespaces |
  grep -i traefik

Affichez les images utilisées :

kubectl get pods --all-namespaces \
  -o custom-columns='NAMESPACE:.metadata.namespace,POD:.metadata.name,IMAGES:.spec.containers[*].image' |
  grep -i traefik

Pour un pod précis :

kubectl exec \
  --namespace NAMESPACE \
  POD_TRAEFIK \
  -- traefik version

Déploiement Helm

Listez les releases :

helm list --all-namespaces |
  grep -i traefik

Affichez les valeurs fournies à la release :

helm get values \
  NOM_DE_LA_RELEASE \
  --namespace NAMESPACE

Étape 2 : vérifier si le provider concerné est activé

Examiner les arguments du pod

kubectl get deployment \
  NOM_DU_DEPLOIEMENT \
  --namespace NAMESPACE \
  -o yaml

Recherchez :

kubernetesIngressNginx

Vous pouvez effectuer une première recherche avec :

kubectl get deployment \
  NOM_DU_DEPLOIEMENT \
  --namespace NAMESPACE \
  -o yaml |
  grep -i -C 3 kubernetesIngressNginx

Examiner les ConfigMaps

kubectl get configmaps \
  --all-namespaces |
  grep -i traefik

Puis :

kubectl get configmap \
  NOM_DE_LA_CONFIGMAP \
  --namespace NAMESPACE \
  -o yaml

Examiner les valeurs Helm

helm get values \
  NOM_DE_LA_RELEASE \
  --namespace NAMESPACE \
  --all

Ne modifiez rien à cette étape. L’objectif est d’établir :

  • quel provider est actif ;
  • où la configuration est définie ;
  • quel outil devra être utilisé pour la mise à jour ;
  • quelle source fait autorité entre Helm, GitOps et les objets appliqués manuellement.

Étape 3 : rechercher les annotations concernées

Vous pouvez rechercher les annotations de réécriture dans tous les Ingress :

kubectl get ingress \
  --all-namespaces \
  -o yaml |
  grep -n -E \
  'nginx\.ingress\.kubernetes\.io/(rewrite-target|use-regex)'

Pour obtenir la configuration complète d’un Ingress identifié :

kubectl get ingress \
  NOM_INGRESS \
  --namespace NAMESPACE \
  -o yaml

Relevez :

  • le chemin public ;
  • la valeur de pathType ;
  • l’expression régulière ;
  • la valeur de rewrite-target ;
  • le service de destination ;
  • les routes sensibles pointant vers le même service ;
  • les middlewares ou annotations d’authentification.

Rechercher les routes protégées du même service

Listez tous les Ingress du namespace :

kubectl get ingress \
  --namespace NAMESPACE \
  -o wide

Puis exportez-les pour analyse :

kubectl get ingress \
  --namespace NAMESPACE \
  -o yaml \
  > ingress-NAMESPACE-avant-correction.yaml

Vous pourrez alors comparer :

  • les backends ;
  • les chemins ;
  • les annotations ;
  • les contrôles d’accès.

Étape 4 : mettre en place une mesure temporaire

La meilleure correction consiste à installer Traefik 3.7.8 ou une version ultérieure contenant le correctif.

Lorsqu’une mise à jour immédiate n’est pas possible, l’avis officiel propose deux mesures complémentaires.

Exiger un séparateur ou la fin du chemin

Une expression plus stricte peut imposer :

  • soit un / ;
  • soit la fin de la chaîne ;

avant de capturer le reste du chemin.

Exemple générique publié dans l’avis :

nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: "/$2"

Avec un chemin structuré sur le principe suivant :

/api(/|$)(.*)

Cette construction empêche qu’une séquence de traversée soit simplement collée au préfixe /api.

Faire appliquer l’authentification par le backend

L’application ne devrait pas dépendre uniquement d’un routeur externe pour protéger ses fonctions les plus sensibles.

Lorsque cela est possible :

  • contrôlez l’identité dans l’application ;
  • vérifiez les autorisations sur chaque fonction ;
  • refusez par défaut les actions administratives ;
  • ne considérez pas un chemin comme une frontière de sécurité suffisante.

Cette défense limite l’impact d’une erreur de routage ou de proxy.

Étape 5 : sauvegarder la configuration avant mise à jour

Sauvegarder les objets Kubernetes

kubectl get ingress \
  --all-namespaces \
  -o yaml \
  > ingress-tous-namespaces-avant-traefik-3.7.8.yaml

Exportez également les éléments administrés par votre méthode de déploiement :

  • dépôt GitOps ;
  • fichiers Helm ;
  • ConfigMaps ;
  • Secrets, selon votre procédure sécurisée ;
  • Services ;
  • Deployments ;
  • politiques réseau ;
  • configuration TLS.

Sauvegarder les valeurs Helm

helm get values \
  NOM_DE_LA_RELEASE \
  --namespace NAMESPACE \
  > traefik-values-avant-3.7.8.yaml

Sauvegardez aussi le manifeste rendu :

helm get manifest \
  NOM_DE_LA_RELEASE \
  --namespace NAMESPACE \
  > traefik-manifest-avant-3.7.8.yaml

Relever l’état courant

kubectl get pods \
  --namespace NAMESPACE \
  -o wide
kubectl get deployment \
  NOM_DU_DEPLOIEMENT \
  --namespace NAMESPACE
kubectl get events \
  --namespace NAMESPACE \
  --sort-by='.lastTimestamp'

Étape 6 : mettre à jour vers Traefik 3.7.8

Cas d’un Deployment Kubernetes

Si l’image est directement gérée dans un Deployment et que le conteneur s’appelle traefik, la commande peut ressembler à :

kubectl set image \
  deployment/NOM_DU_DEPLOIEMENT \
  traefik=traefik:v3.7.8 \
  --namespace NAMESPACE

Surveillez le déploiement :

kubectl rollout status \
  deployment/NOM_DU_DEPLOIEMENT \
  --namespace NAMESPACE

Vérifiez les pods :

kubectl get pods \
  --namespace NAMESPACE \
  -o wide

Cas d’une installation Helm

Sauvegardez d’abord les valeurs actuelles.

Mettez à jour les informations du dépôt :

helm repo update

Préparez un fichier de valeurs dans lequel l’image de Traefik utilise au minimum :

image:
  tag: v3.7.8

Puis réalisez la mise à jour en utilisant le nom réel de la release, son namespace et le chart prévu par votre organisation :

helm upgrade \
  NOM_DE_LA_RELEASE \
  traefik/traefik \
  --namespace NAMESPACE \
  --values traefik-values-corrigees.yaml

Surveillez ensuite le rollout.

Cas de Docker Compose

Repérez le service Traefik dans le fichier Compose :

services:
  traefik:
    image: traefik:v3.7.8

Validez la configuration :

docker compose config

Récupérez l’image :

docker compose pull traefik

Recréez uniquement le service concerné :

docker compose up \
  --detach \
  --no-deps \
  traefik

Vérifiez l’image et les journaux :

docker compose ps
docker compose logs \
  --tail 200 \
  traefik

Étape 7 : vérifier que la version corrigée est active

Sous Kubernetes :

kubectl get pods \
  --namespace NAMESPACE \
  -o custom-columns='POD:.metadata.name,IMAGE:.spec.containers[*].image,READY:.status.containerStatuses[*].ready'

Puis :

kubectl exec \
  --namespace NAMESPACE \
  POD_TRAEFIK \
  -- traefik version

Sous Docker :

docker exec \
  NOM_DU_CONTENEUR \
  traefik version

Le résultat doit indiquer :

3.7.8

ou une version ultérieure explicitement corrigée.

Étape 8 : contrôler les journaux

Journaux applicatifs

Sous Kubernetes :

kubectl logs \
  --namespace NAMESPACE \
  deployment/NOM_DU_DEPLOIEMENT \
  --since=30m

Sous Docker Compose :

docker compose logs \
  --since=30m \
  traefik

Recherchez :

  • erreurs de chargement de configuration ;
  • provider indisponible ;
  • route ignorée ;
  • problème de certificat ;
  • middleware inconnu ;
  • erreurs HTTP inhabituelles ;
  • redémarrages.

Journaux d’accès

Si les journaux d’accès sont activés, examinez les requêtes présentant :

  • des segments .. ;
  • des variantes encodées de points ;
  • des chemins inhabituels juste après un préfixe public ;
  • une réponse 200 inattendue sur une fonction sensible ;
  • des appels anonymes sur des routes administratives.

Cette recherche peut générer des faux positifs. Elle doit être corrélée avec :

  • le chemin final reçu par le backend ;
  • l’identité du client ;
  • la méthode HTTP ;
  • le code de réponse ;
  • l’heure ;
  • les journaux applicatifs ;
  • les actions réalisées.

Étape 9 : tester le fonctionnement après correction

Vérifier les routes publiques

Contrôlez les fonctions normalement accessibles sans authentification :

  • pages publiques ;
  • API publiques ;
  • ressources statiques ;
  • health checks ;
  • redirections.

Vérifier les routes protégées

Contrôlez :

  • BasicAuth ;
  • ForwardAuth ;
  • SSO ;
  • restrictions IP ;
  • politiques réseau ;
  • permissions applicatives.

Une requête non authentifiée vers une route protégée doit produire le comportement attendu :

401 Unauthorized

ou :

403 Forbidden

selon l’architecture.

Tester les réécritures légitimes

Vérifiez notamment :

  • chemin avec et sans barre finale ;
  • paramètres de requête ;
  • caractères encodés légitimes ;
  • sous-chemins ;
  • appels GET et autres méthodes réellement utilisées ;
  • API clientes existantes.

Tester en laboratoire les chemins anormaux

Dans un environnement isolé, contrôlez qu’une réécriture créant un chemin non normalisé est refusée et ne donne jamais accès à une ressource protégée.

Ne réalisez pas ce test sur un service de production pouvant modifier des données.

Que faire en cas de suspicion d’exploitation ?

La correction ferme la vulnérabilité, mais n’annule pas une action déjà réalisée.

En cas de comportement suspect :

  1. conservez les journaux Traefik, Kubernetes et applicatifs ;
  2. relevez les adresses sources et les horodatages ;
  3. identifiez les endpoints qui ont pu être atteints ;
  4. vérifiez les actions administratives réalisées ;
  5. recherchez les créations de comptes, jetons ou clés ;
  6. révoquez les secrets potentiellement exposés ;
  7. analysez le backend et les données concernées ;
  8. documentez la chronologie ;
  9. sollicitez une assistance spécialisée si l’impact n’est pas maîtrisé.

Selon les données et obligations de l’organisation, une notification peut être nécessaire.

Les erreurs à éviter

Mettre à jour uniquement le chart sans vérifier l’image

Le chart peut changer tandis que l’image Traefik reste sur une version vulnérable.

Changer uniquement l’expression régulière

La mesure temporaire réduit le risque d’une règle donnée, mais d’autres Ingress peuvent rester vulnérables.

Considérer sanitizePath=true comme suffisant

Le bulletin indique explicitement que cette option seule ne corrige pas le scénario.

Protéger uniquement la route au niveau du proxy

Une fonction administrative sensible doit également contrôler les autorisations dans l’application lorsque cela est possible.

Tester avec une requête dangereuse en production

Un backend peut accepter une action d’écriture. Un test peut donc provoquer un changement réel.

Oublier les environnements secondaires

Vérifiez :

  • production ;
  • préproduction ;
  • recette ;
  • clusters de secours ;
  • environnements clients ;
  • manifestes stockés mais temporairement arrêtés.

Checklist de remédiation

  • ☐ La version réellement exécutée a été relevée.
  • ☐ Le provider Kubernetes Ingress NGINX a été recherché.
  • ☐ Les annotations rewrite-target ont été inventoriées.
  • ☐ Les routes publiques et protégées pointant vers un même backend ont été analysées.
  • ☐ Les valeurs Helm ou manifestes ont été sauvegardés.
  • ☐ Traefik 3.7.8 ou une version ultérieure corrigée a été déployé.
  • ☐ Le rollout s’est terminé correctement.
  • ☐ La version active a été vérifiée dans le pod ou le conteneur.
  • ☐ Les routes publiques fonctionnent.
  • ☐ Les routes protégées imposent toujours l’authentification.
  • ☐ Les journaux d’accès ont été examinés.
  • ☐ Les secrets ont été révoqués en cas de suspicion.
  • ☐ La protection des fonctions sensibles a été vérifiée côté backend.
  • ☐ La documentation de l’infrastructure a été mise à jour.

Conclusion

La vulnérabilité GHSA-8rxv-jg7p-wvg3 illustre une limite importante des architectures reposant sur plusieurs couches de routage.

Une requête peut être considérée comme publique au moment du choix de la route, puis être transformée en un chemin sensible avant son traitement par l’application.

Dans le scénario publié, l’exploitation nécessite une configuration précise :

  • Traefik 3.7 ;
  • le provider Kubernetes Ingress NGINX ;
  • une réécriture par expression régulière permissive ;
  • une route protégée vers le même backend ;
  • une normalisation du chemin par ce backend.

Ces conditions limitent le périmètre, mais l’impact potentiel reste élevé : lecture de données sensibles ou appel de fonctions normalement protégées.

La réponse recommandée est claire :

  1. inventorier les instances ;
  2. rechercher le provider et les annotations concernés ;
  3. installer Traefik 3.7.8 ou une version corrigée plus récente ;
  4. vérifier les routes et l’authentification ;
  5. examiner les journaux ;
  6. renforcer les contrôles côté application.

Besoin de vérifier votre reverse proxy ?

AGE-Info accompagne les TPE et PME dans l’audit et la sécurisation de leurs services exposés.

Nous pouvons notamment :

  • inventorier les reverse proxies ;
  • vérifier les versions ;
  • analyser les règles de routage ;
  • sécuriser les accès administratifs ;
  • préparer et tester les mises à jour ;
  • centraliser les journaux ;
  • documenter une procédure de remédiation.