Deux d’entre eux affichent des scores CVSS de 8,8, exigeant que les administrateurs mettent à niveau vers les dernières versions du contrôleur.
Quatre vulnérabilités de sécurité ont été découvertes dans le contrôleur de trafic open source Ingress NGINX, largement utilisé par les organisations dans les déploiements Kubernetes.
Ils ne peuvent être corrigés qu’en effectuant une mise à niveau vers la dernière version.
Sur les quatre trous, deux sont plus sérieux, car ils affichent des scores CVSS de 8,8 :
CVE-2026-1580 est un problème de validation d’entrée incorrecte. Si le contrôleur Ingress NGINX est configuré avec une configuration par défaut qui inclut les erreurs HTTP 401 ou 403, et si le backend par défaut configuré est défectueux et ne respecte pas l’en-tête HTTP X-Code, alors une entrée avec l’annotation est accessible même lorsque l’authentification échoue.
CVE-2026-24512 est une vulnérabilité d’injection de configuration où le champ Ingress peut être utilisé pour injecter la configuration dans nginx. Cela peut conduire à l’exécution de code arbitraire dans le contexte du contrôleur ingress-nginx et à la divulgation de secrets accessibles au contrôleur.
« Il s’agit d’une vulnérabilité sérieuse », a commenté Kellman Meghu, CTO de DeepCove Cybersecurity au Canada, qui a de l’expérience avec Ingress NGINX. « Si je pouvais l’exploiter, je pourrais faire en sorte que la passerelle Ingress crée un chemin directement vers les ressources internes. C’est comme ouvrir l’intérieur qui ne devrait jamais être exposé. Cela conduira-t-il à une exposition supplémentaire ou à des piratages ? Probablement, mais en termes d’impact, c’est une première étape pour accéder à l’environnement, et à partir de là, cela pourrait aller plus loin, la moindre d’entre elles étant une interruption des services. »
NGINX est un proxy inverse/équilibreur de charge qui agit généralement comme récepteur de trafic Web frontal et le dirige vers le service d’application pour la transformation des données. Ingress NGINX est une version utilisée dans Kubernetes comme contrôleur du trafic entrant dans l’infrastructure. Il se charge de mapper le trafic vers les pods de conteneurs exécutant des tâches sans exposer les pods eux-mêmes. Meghu affirme qu’Ingress NGINX est le principal point d’entrée du trafic et est efficace en raison de sa capacité à recharger sa configuration à la volée, lui permettant de s’adapter aux changements au sein d’un cluster Kubernetes.
Ces vulnérabilités n’affectent que les versions 1.13.7 et inférieures d’Ingress NGINX, ainsi que 1.14.3 et inférieures, si elles sont installées sur un cluster Kubernetes.
L’avertissement intervient quelques semaines seulement avant, comme annoncé lors de la KubeCon en novembre, la fin du support d’Ingress NGINX. À partir de mars, le projet ne recevra plus de maintenance active, de correctifs de sécurité ou de corrections de bugs.
Depuis, les experts exhortent les administrateurs Kubernetes à passer à un nouveau contrôleur. Ils recommandent l’API Kubernetes Gateway comme norme pour la gestion du trafic. Meghu note qu’il est indépendant du fournisseur et largement utilisé. D’autres options sont des contrôleurs tels que Cilium Ingress, Traefik ou HAProxy Ingress.
En plus de CVE-2026-24512, les autres nouvelles vulnérabilités sont CVE-2026-24513, considérée par Meghu comme un risque faible puisqu’un attaquant doit disposer d’une configuration contenant des erreurs spécifiques à exploiter, et CVE-2026-24514, que Meghu considère comme un risque moyen. Le contrôleur pourrait faire l’objet d’un déni de service si un attaquant le submergeait de requêtes.
Ce ne sont que les problèmes les plus récents avec Ingress NGINX. Il y a un peu plus d’un an, des chercheurs de Wiz ont découvert un groupe de trous baptisé IngressNightmare. Ils peuvent permettre à des utilisateurs non authentifiés d’injecter des configurations NGINX malveillantes et d’exécuter du code malveillant dans le pod Ingress NGINX, exposant potentiellement tous les secrets du cluster et conduisant à la prise de contrôle du cluster.
« Bien qu’il n’y ait rien de nouveau dans (les nouvelles vulnérabilités), elles rappellent brutalement à tous les administrateurs que s’ils n’ont pas commencé la migration, ils doivent commencer immédiatement, avant le retrait d’Ingres NGINX le mois prochain. Compte tenu de son retrait prochain, la migration est la meilleure stratégie pour atténuer ces vulnérabilités. »
