Une vulnérabilité récemment découverte dans le fournisseur expérimental ingress-nginx de Traefik a désactivé silencieusement la vérification des certificats TLS pendant cinq mois — alors même que les opérateurs l’avaient activée dans la configuration.
La faille a inversé une annotation de sécurité critique, exposant les services HTTPS en aval à une interception de type « adversaire au milieu » dans les environnements Kubernetes.
La vulnérabilité a exposé « … les backends HTTPS à des attaques de type adversaire au milieu », ont déclaré les chercheurs d’AISLE.
Stanislav Fort, cofondateur et directeur scientifique d’AISLE, a ajouté : « Les scanners traditionnels passent complètement à côté de ce problème, car le code semble correct et passe tous les tests. Le bug ne se situe pas dans la syntaxe, mais dans la relation sémantique entre deux systèmes. Il s’agit d’une incohérence logique qui nécessite de raisonner sur l’intention, et pas seulement de faire de la correspondance de motifs. »
Une petite mauvaise configuration aux lourdes conséquences
Traefik est l’un des contrôleurs d’ingress cloud-native les plus déployés au monde, avec plus de 60 000 étoiles sur GitHub et plus de 3 milliards de téléchargements.
Il achemine le trafic de services financiers, de plateformes SaaS, de systèmes de santé et de clusters Kubernetes d’entreprise sur AWS, Azure, GCP et des environnements sur site.
Comme les annotations dans Kubernetes servent de politiques à grande échelle, un seul paramètre de sécurité inversé peut affaiblir les protections sur des milliers de routes.
De nombreuses équipes ont déployé le fournisseur ingress-nginx de Traefik précisément pour conserver les configurations de sécurité de type NGINX — notamment la vérification des certificats des backends. Au lieu de cela, la vérification a été désactivée sans avertissement.
Comment le bug de vérification TLS de Traefik est survenu
La vulnérabilité (CVE-2025-66491) découlait d’un décalage sémantique entre l’annotation NGINX proxy-ssl-verify et le champ InsecureSkipVerify de Go.
Dans NGINX, définir proxy-ssl-verify: “on” active la vérification des certificats des backends, tandis que dans l’implémentation TLS de Go, définir InsecureSkipVerify: true désactive la vérification.
Le fournisseur ingress-nginx de Traefik a incorrectement transposé ces comportements, en utilisant la logique suivante : InsecureSkipVerify: strings.ToLower(ptr.Deref(cfg.ProxySSLVerify, “off”)) == “on”.
Ainsi, définir l’annotation sur « on » désactivait involontairement la vérification, tandis que la définir sur « off » l’activait.
La suite de tests unitaires a renforcé cette inversion en définissant le comportement inverse comme résultat attendu, ce qui a permis à la faille de passer inaperçue dans la CI.
Le problème devient dangereux lorsqu’un attaquant peut se positionner sur le chemin réseau entre Traefik et un service backend — par exemple via une usurpation ARP, un side-car compromis ou des politiques réseau mal configurées.
Lorsque la vérification est désactivée, un attaquant peut présenter un certificat falsifié, intercepter et déchiffrer le trafic, voler des identifiants ou des jetons de session, modifier les réponses ou rediriger le trafic des services, tout en laissant la connexion chiffrée sembler normale aux opérateurs.
Cela présente un risque particulier dans les clusters mutualisés, les environnements hybrides ou les architectures dépourvues d’une mise en œuvre cohérente du mTLS.
Le bug concernait les versions v3.5.0 à v3.6.2 de Traefik et a été corrigé dans la version v3.6.3.
Réduire les risques liés au bug de vérification TLS de Traefik
Pour remédier à cette vulnérabilité, il faut à la fois effectuer la mise à niveau vers la version corrigée de Traefik et renforcer la manière dont les politiques TLS sont appliquées, validées et surveillées dans l’environnement.
- Passez à Traefik v3.6.3 pour appliquer le correctif complet, ou définissez temporairement proxy-ssl-verify: “off” ou supprimez l’annotation afin de maintenir une vérification TLS correcte.
- Auditez les ressources ingress et les annotations à la recherche de paramètres TLS inversés ou non sécurisés, et limitez les personnes autorisées à modifier la configuration ingress au moyen de contrôles RBAC plus stricts.
- Utilisez des contrôleurs d’admission ou des moteurs de politiques comme OPA/Gatekeeper ou Kyverno pour imposer des configurations TLS sécurisées et bloquer les valeurs d’annotation dangereuses.
- Imposez le mTLS ou un chiffrement fort entre services afin de moins dépendre de la seule vérification TLS au niveau de l’ingress.
- Surveillez le trafic backend à la recherche d’anomalies telles que des chaînes de certificats inattendues, des changements de routage ou des schémas irréguliers de communication entre services.
- Examinez les tests de CI et les pipelines de configuration à la recherche d’incohérences sémantiques et mettez en place une détection de dérive pour empêcher la réapparition de paramètres TLS non sécurisés.
En prenant ces mesures, les organisations peuvent maintenir des protections TLS plus fiables et réduire le risque que des problèmes de configuration passent inaperçus.
Les mauvaises configurations invisibles dans les architectures cloud-native
CVE-2025-66491 met en évidence un problème plus général des systèmes cloud-native : garantir que l’intention de la configuration est correctement transposée entre les différents composants qui appliquent les politiques de sécurité.
Bien que le bug sous-jacent ne tienne qu’à quelques caractères, il est apparu dans une infrastructure largement utilisée et a produit un comportement différent de celui attendu par les opérateurs.
Ce type de problème peut survenir dans des architectures complexes à plusieurs niveaux, où les paramètres définis dans un système — comme les annotations NGINX — doivent être transposés dans un autre, comme la configuration TLS de Go.
Ces divergences peuvent être difficiles à détecter, car elles peuvent passer les tests de CI et rester ignorées des outils d’analyse traditionnels, pour ne devenir visibles qu’après un examen plus approfondi ou prenant en compte l’ensemble du système.
des approches comme lezero-trust qui mettent l’accent sur une validation explicite à chaque niveau.