Un ensemble de cinq lacunes de sécurité critiques a été divulguée dans le Contrôleur nginx entrant pour Kubernetes Cela pourrait entraîner une exécution non authentifiée de code distant, mettant plus de 6 500 clusters à risque immédiat en exposant le composant à Internet public.
Les vulnérabilités (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098 et CVE-2025-1974), ont attribué un score CVSS de 9,8, ont été collectivement nommés INDERNIGHTHNINGHNIGHTS par Wiz Wiz. Il convient de noter que les lacunes n’ont pas d’impact Contrôleur à entronne de Nginxqui est une autre implémentation du contrôleur entrant pour Nginx et Nginx Plus.
“L’exploitation de ces vulnérabilités conduit à un accès non autorisé à tous les secrets stockés dans toutes les espaces de noms du cluster Kubernetes par les attaquants, ce qui peut entraîner une prise de contrôle des cluster”, a déclaré la société dans un rapport partagé avec les actualités des pirates.
IngressnightMare, à la base, affecte le contrôleur d’admission Composant du contrôleur nginx entrant pour Kubernetes. Environ 43% des environnements cloud sont vulnérables à ces vulnérabilités.
Le contrôleur Nginx Internx utilise Nginx comme proxy inverse et équilibreur de charge, ce qui permet d’exposer les routes HTTP et HTTPS de l’extérieur d’un cluster vers des services à l’intérieur.
La vulnérabilité tire parti du fait que les contrôleurs d’admission, déployés dans un pod Kubernetes, sont accessibles sur le réseau sans authentification.
Plus précisément, il implique d’injecter à distance une configuration arbitraire de Nginx en envoyant un objet d’entrée malveillant (AKA AdmissionReview demandes) directement au contrôleur d’admission, entraînant une exécution de code sur le pod du contrôleur Nginx Ingress.
“Les privilèges élevés du contrôleur d’admission et l’accessibilité du réseau sans restriction créent un chemin d’escalade critique”, a expliqué Wiz. “L’exploitation de cette faille permet à un attaquant d’exécuter du code arbitraire et d’accéder à tous les secrets de cluster à travers les espaces de noms, ce qui pourrait conduire à une prise de contrôle complète du cluster.”
Les lacunes sont répertoriées ci-dessous –
- CVE-2025-24514 – Auth-Url Annotation Injection
- CVE-2025-1097 – Auth-TLS-Match-CN Annotation Injection
- CVE-2025-1098 – Injection de miroir UID
- CVE-2025-1974 – Exécution du code de configuration Nginx
Dans un scénario d’attaque expérimental, un acteur de menace pourrait télécharger une charge utile malveillante sous la forme d’une bibliothèque partagée sur le pod en utilisant la fonction tampon du corps client de Nginx, suivie par l’envoi d’une demande d’admission à la demande d’admission.
La demande, à son tour, contient l’une des injections de directives de configuration susmentionnées qui provoquent le chargement de la bibliothèque partagée, conduisant efficacement à l’exécution du code distant.
Hillai Ben-Sasson, chercheur à la sécurité du cloud chez Wiz, a déclaré au Hacker News que la chaîne d’attaque implique essentiellement d’injecter une configuration malveillante et de l’utiliser pour lire des fichiers sensibles et exécuter du code arbitraire. Cela pourrait par la suite permettre à un attaquant de maltraiter un fort compte de service afin de lire les secrets de Kubernetes et, finalement, de faciliter la prise de contrôle des cluster.
Après la divulgation responsable, les vulnérabilités ont été abordées dans les versions de contrôleur nginx nginx 1.12.1, 1.11.5 et 1.10.7.
Les utilisateurs sont recommandés à mettre à jour vers la dernière version dès que possible et à s’assurer que le Entrée Webhook Point de terminaison n’est pas exposé à l’extérieur.
En tant qu’atténuations, il est conseillé de limiter uniquement le serveur API Kubernetes pour accéder au contrôleur d’admission et désactiver temporairement le composant du contrôleur d’admission s’il n’est pas nécessaire.