Les vulnérabilités surnommées IngressnightMare peuvent permettre aux utilisateurs non authentifiés d’injecter des configurations de Nginx malveillantes et d’exécuter du code malveillant dans le pod nginx entrant, exposant potentiellement tous les secrets de cluster et conduisant à la prise de contrôle des grappes.
Le projet Kubernetes a publié des correctifs pour cinq vulnérabilités dans un composant populaire largement utilisé appelé le contrôleur Nginx Ingress qui est utilisé pour acheminer le trafic externe vers les services Kubernetes. S’il est exploité, la faille pourrait permettre aux attaquants de reprendre complètement des grappes entières.
«Sur la base de notre analyse, environ 43% des environnements cloud sont vulnérables à ces vulnérabilités, nos recherches découvrant plus de 6 500 clusters, y compris les sociétés du Fortune 500, qui exposent publiquement les contrôles de contrôle des contrôleurs de Kubernetes vulnérables», a écrit des chercheurs de la société de sécurité dans le cloud qui ont trouvé et rapporté les Flaws.
Collectivement surnommée IngressnightMare par l’équipe de recherche WIZ, les vulnérabilités sont suivies sous le nom de CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 et CVE-2025-1974. Ils ont été fixés dans les versions 1.12.1 et 1.11.5 du contrôleur nginx entrant (ining-nginx) libéré lundi.
Injection de configuration entrée non authentifiée
Kubernetes est le système d’orchestration des conteneurs le plus populaire qui est utilisé pour automatiser le déploiement d’applications dans des environnements cloud en les divisant en réseaux de microservices qui s’exécutent indépendamment dans leurs propres conteneurs sécurisés ou groupe de conteneurs appelés pods.
L’une des fonctionnalités de Kubernetes qui permet d’exposer les charges de travail à Internet est appelée entrée et permet aux administrateurs d’acheminer le trafic entrant vers différents services backend en fonction des règles définies via l’API Kubernetes.
Il existe plusieurs contrôleurs Ingress disponibles, mais Ingress-Nginx qui exploite le serveur Web Nginx et le proxy inversé, est l’un des plus populaires et couramment utilisé comme exemple dans la documentation officielle. Selon Wiz, plus de 41% des clusters Kubernetes orientés Internet exécutent Ingress-Nginx.
Le contrôleur d’admission dans Ingress-Nginx est utilisé pour traiter les objets entrants entrants, créer des configurations Nginx correspondantes en fonction d’eux, puis les valider et les utiliser pour décider comment et où acheminer les demandes. Les vulnérabilités trouvées par Wiz permettent à un attaquant d’injecter des paramètres de configuration qui, lorsqu’ils sont validés, font que le validateur NGINX exécute le code arbitraire.
« La gestion appropriée de ces paramètres de configuration Nginx est cruciale, car Ingress-Nginx doit permettre aux utilisateurs une flexibilité significative tout en les empêchant de tromper accidentellement Nginx de faire des choses qu’il ne devrait pas », a déclaré l’équipe de Kubernetes dans un article de blog.
Le problème est que le pod Ingress-Nginx a des privilèges élevés et une accessibilité du réseau sans restriction par conception. Plus important encore, il a accès à tous les secrets à l’échelle du cluster par défaut, ce qui signifie qu’un attaquant avec une action d’exécution de code dans ce pod peut fuir ces secrets et prendre le contrôle de l’ensemble du cluster.
La vulnérabilité CVE-2025-1974 est la plus grave et est évaluée avec un score de gravité de 9,8 sur l’échelle CVSS. Il permet à toute personne ayant un accès au réseau POD d’exploiter les autres vulnérabilités d’injection de configuration, ce qui nécessiterait autrement des actions privilégiées pour exploiter.
« Lorsqu’il est combiné avec les autres vulnérabilités d’aujourd’hui, le CVE-2025-1974 signifie que tout sur le réseau POD a de bonnes chances de prendre le contrôle de votre cluster Kubernetes, sans références ni accès administratif requis », ont averti les Kubernetes. «Dans de nombreux scénarios courants, le réseau POD est accessible à toutes les charges de travail de votre VPC cloud, ou même de quelqu’un connecté à votre réseau d’entreprise! C’est une situation très grave.»
Deux façons d’atténuer les défauts
Le meilleur correctif consiste à mettre à niveau le composant Ingress-Nginx vers l’une des versions correctes. Les administrateurs peuvent déterminer s’il est utilisé à l’intérieur de leurs grappes en tapant: Kubectl Get Pods –All-Namespaces –Selector App.kubernetes.io/name=ingress-nginx
Dans les situations où une mise à niveau de version immédiate n’est pas possible, les administrateurs peuvent réduire le risque en supprimant la validation de la configuration de webhook appelée Ingress-nginx-Admission et en supprimant l’argument du conteneur ou un Daemonsset du conteneur du contrôleur de contrôle-contrôleur ingétre. Si Ingress-Nginx a été installé à l’aide de Helm, il peut être réinstallé avec Controller.AdmissionWebhooks.enabled = false.
Cela atténuera le CVE-2025-1974 en particulier, ce qui facilite l’exploitation des autres vulnérabilités sans authentification. Cependant, le contrôleur d’admission de validation ne doit pas rester désactivé pendant longtemps car il fournit des garanties contre les configurations de mauvaise entrée pour légitimer les utilisateurs.
