9 min de lecture - Correctifs Traefik : revalider la frontière réseau, pas seulement la version

Un reverse proxy peut rester disponible, présenter des certificats valides et réussir tous ses contrôles de disponibilité tout en appliquant une politique de sécurité moins stricte que celle décrite par sa configuration. Voilà la leçon opérationnelle de quatre avis Traefik publiés le 21 août 2026.

La faille la plus grave permet à un client distant non authentifié de contourner toute route protégée par le middleware digestAuth de Traefik. Deux autres concernent l’authentification par certificat client lorsque des options TLS entrent en conflit. La quatrième franchit une limite d’espace de noms Kubernetes par l’intermédiaire d’une annotation de middleware sur un Service.

Les sources n’indiquent ni chemin universel ni exploitation observée. Répondez donc selon la configuration et l’exposition. Corrigez d’abord, mais ne clôturez pas le ticket dès que « le tag du conteneur a changé ». Revalidez la politique que la frontière réseau doit faire respecter.

Ce qui a été publié le 21 août

L’avis critique sur digestAuth concerne Traefik jusqu’à la version 2.11.54 et la branche 3.x jusqu’à la version 3.7.10. Pour un nom d’utilisateur inconnu, le middleware transmettait un secret vide à sa bibliothèque d’authentification Digest. Comme les autres valeurs nécessaires au contrôle étaient choisies par le client ou fournies dans le défi du serveur, un client distant pouvait calculer une réponse acceptée sans nom d’utilisateur ni mot de passe valides. Selon l’éditeur, toute route accessible utilisant digestAuth était concernée, y compris un tableau de bord ou une API ainsi protégés.

La deuxième faille couvre davantage de versions, mais dépend d’une configuration plus précise. L’avis sur les options TLS des routeurs multihôtes explique qu’un conflit sur un nom d’hôte pouvait conduire un routeur multihôte à appliquer les options TLS par défaut à ses autres noms d’hôte. Un hôte censé exiger un certificat client pouvait alors devenir accessible sans ce certificat. Le correctif ajoute core.strictTLSOptions, qui place les routeurs en conflit en erreur au lieu de revenir aux options par défaut. Point essentiel : l’option reste désactivée par défaut pour préserver la compatibilité et doit être activée explicitement.

L’avis sur les objets Ingress partageant le même hôte concerne Traefik 3.7.0 à 3.7.10 et son fournisseur Kubernetes Ingress NGINX. Deux objets Ingress partageant le même hôte, la même autorité de certification cliente et le même mode d’authentification pouvaient produire des noms d’options TLS distincts. Traefik interprétait ce résultat comme un conflit et revenait à la configuration TLS par défaut, qui ne demandait pas de certificat client. La version 3.7.11 génère désormais le nom à partir de la politique mTLS réelle.

Enfin, l’avis sur l’isolation entre fournisseurs et espaces de noms concerne Traefik 3.7.1 à 3.7.10. Le fournisseur Kubernetes Ingress appliquait sa liste d’autorisation crossProviderNamespaces à certaines annotations, mais pas à l’annotation de middleware d’un Service. Dans un environnement mutualisé, un locataire exclu de la liste pouvait donc rattacher à son Service un middleware appartenant à l’opérateur. Si ce middleware injectait un secret vers le backend, le locataire pouvait le récupérer sur un backend qu’il contrôlait.

L’avis CERTFR-2026-AVI-1070 du CERT-FR regroupe indépendamment ces quatre publications parmi les risques de contournement de politique de sécurité et indique comme affectées les versions antérieures à 2.11.55 et 3.7.11. Les avis de l’éditeur restent la source la plus précise pour les prérequis de configuration.

Construisez une matrice d’exposition avant de fixer les priorités

Un scanner de versions vous dit où s’exécutent d’anciens binaires. Il ne vous dit pas quelle promesse de sécurité est menacée. Associez l’inventaire des versions à la configuration et à l’accessibilité réseau.

Ce tableau ne doit pas servir de prétexte pour retarder la mise à jour. Il permet de dimensionner le confinement, les tests et l’investigation. Une route publique utilisant digestAuth et un cluster à locataire unique n’ayant jamais activé la fonction concernée n’ont pas la même exposition, même s’ils exécutent le même binaire.

Corrigez avec un plan de déploiement réversible

Faites évoluer les déploiements v2 maintenus vers la version 2.11.55 et les déploiements v3 maintenus vers la version 3.7.11, ou vers une version ultérieure prise en charge par l’éditeur, après avoir relu les avis à jour. Selon l’éditeur, les anciennes branches mineures ne recevront pas leur propre correctif : elles nécessitent donc une migration vers une branche maintenue et corrigée.

Traitez ce déploiement comme une modification de politique en frontière réseau :

1. Gelez les modifications sans rapport. Capturez les configurations, le digest de déploiement et l’inventaire des routes.
2. Confinez l’exposition la plus nette. Si digestAuth protège une route accessible, restreignez-la à l’aide d’une couche réseau ou d’identité indépendante jusqu’au déploiement et au test de la version corrigée.
3. Déployez par cohortes. Commencez hors production, puis utilisez une cohorte de production avec retour arrière rapide. Surveillez les routeurs rejetés, TLS, les réponses 401/403 et les backends.
4. Décidez du traitement strict des conflits TLS. Testez core.strictTLSOptions en préproduction, corrigez chaque conflit révélé, puis activez l’option là où le comportement d’échec sécurisé est approprié. La mise à jour seule ne l’active pas.
5. Conservez les preuves. Enregistrez les digests d’image, commits de configuration, horaires, tests négatifs et exceptions. Une capture de version ne prouve pas chaque frontière de sécurité.

Testez le chemin refusé, pas seulement le cas nominal

La plupart des tests de fumée d’une passerelle prouvent qu’une requête autorisée aboutit. Ces avis portent sur des requêtes qui devraient échouer ; la recette doit donc inclure des cas négatifs.

• Envoyez une requête sans identifiants, puis avec un nom d’utilisateur inconnu, vers chaque route précédemment protégée par digestAuth. Attendez un refus à la frontière et aucune requête côté backend.
• Connectez-vous sans certificat client à chaque hôte mTLS d’un routeur multihôte. Recommencez après modification d’un routeur partageant le point d’entrée.
• Pour Kubernetes Ingress NGINX, recréez la condition du même hôte dans un espace contrôlé et vérifiez l’exigence de certificat client.
• Depuis un compte de service limité à un espace de noms, tentez chaque référence inter-fournisseurs interdite. Vérifiez l’admission et le comportement à l’exécution ; une simple revue des manifestes ne suffit pas.
• Interrogez le tableau de bord et l’API depuis chaque point d’entrée publié. L’étiquette « interne » ne constitue pas un contrôle réseau.
• Vérifiez que les journaux enregistrent la requête rejetée sans considérer comme fiable une identité fournie par l’attaquant.

Automatisez ces contrôles autour des modifications de configuration. Un nouvel hôte, objet Ingress ou middleware peut créer une interaction invisible dans chaque manifeste pris isolément. Notre guide de sécurité Kubernetes présente les autres couches ; testez aussi la configuration effectivement résolue par la passerelle.

Examinez les preuves sans déclarer trop vite une compromission

L’avis digestAuth précise que des noms forgés peuvent apparaître comme des identités authentifiées. Comparez les succès sur les routes concernées avec la liste d’utilisateurs, les adresses sources, chemins, journaux backend et actions en aval. Pour mTLS, recherchez les succès sans attributs de certificat attendus et les conflits de configuration. Pour les espaces de noms, examinez les annotations de Service et les références inter-fournisseurs.

Ce sont des pistes, pas des indicateurs universels. L’absence d’un journal suspect ne prouve pas l’absence d’incident ; un nom inhabituel ne suffit pas à en déclarer un. Préservez les preuves et impliquez des spécialistes qualifiés si les constats sont conséquents.

La décision d’architecture après l’urgence

Le proxy concentre souvent TLS, authentification, propagation d’identité et isolation des locataires. Après l’urgence, déterminez quelles garanties exigent une application indépendante. Protégez les surfaces d’administration par une frontière supplémentaire, faites valider l’identité et l’autorisation par les backends, et contrôlez les capacités de chaque locataire dans un cluster mutualisé.

Restez proportionné : même un petit déploiement a besoin d’un responsable, d’une version maintenue, d’un inventaire des routes, d’une reprise testée et de tests négatifs. Pour une plateforme auto-hébergée, intégrez la passerelle au modèle d’exploitation de l’auto-hébergement plutôt que d’en faire un détail invisible.

Sources et limites

• L’avis Traefik sur digestAuth, publié le 21 août 2026, documente le contournement critique sans authentification, les versions affectées et corrigées, ainsi qu’une piste d’investigation.
• L’avis Traefik sur les options TLS multihôtes, publié le 21 août 2026, documente le repli mTLS et le comportement optionnel de core.strictTLSOptions.
• L’avis Traefik sur les objets Ingress partageant un hôte, publié le 21 août 2026, concerne le fournisseur Kubernetes Ingress NGINX sur les versions 3.7 indiquées.
• L’avis Traefik sur les espaces de noms inter-fournisseurs, publié le 21 août 2026, concerne le chemin indiqué pour l’annotation de Service Kubernetes Ingress.
• L’avis CERTFR-2026-AVI-1070 du CERT-FR, publié le 21 août 2026, qualifie indépendamment ces quatre publications de risques de contournement de politique de sécurité et renvoie vers les correctifs de l’éditeur.

Les avis décrivent le code affecté et les conditions de configuration ; ils n’établissent ni l’exposition ni la compromission de tous les déploiements Traefik et ne signalent pas d’exploitation observée. Les versions, branches maintenues et recommandations peuvent évoluer. Relisez les sources de l’éditeur avant d’agir, testez dans votre propre environnement et faites appel à une expertise qualifiée pour toute décision liée à un incident ou à une obligation réglementaire.

À retenir

Les publications Traefik actuelles ne racontent pas seulement une histoire de correctifs. Elles montrent comment une passerelle peut résoudre plusieurs objets raisonnables pris isolément en une politique d’exécution moins stricte que celle voulue par l’opérateur.

Mettez à niveau, confinez les routes digestAuth accessibles, examinez TLS et les espaces de noms, puis testez des requêtes non autorisées. Le travail est terminé lorsque les chemins interdits le restent, pas lorsque la version affiche un nouveau numéro.