Le projet Kubernetes (de la CNCF) a publié des correctifs pour cinq vulnérabilités dans un composant populaire largement utilisé Ingress Nginx Controller servant à acheminer le trafic externe vers les services Kubernetes. Si elle est exploitée, un des failles pourraient permettre à des attaquants de prendre complètement le contrôle de clusters de conteneurs entiers. « Sur la base de notre analyse, environ 43 % des environnements cloud sont vulnérables, nos recherches ayant permis de découvrir plus de 6 500 clusters, y compris des entreprises du Fortune 500, qui exposent publiquement les contrôleurs Kubernetes Ingress à l'Internet public - ce qui leur fait courir un risque critique immédiat », écrivent les chercheurs de la société de sécurité cloud Wiz - racheté par Google 32 Md$ - qui ont trouvé et signalé les failles. Collectivement baptisées IngressNightmare par l'équipe de recherche, ces brèches sont répertoriées en tant que CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 et CVE-2025-1974. Elles ont été corrigées dans les versions 1.12.1 et 1.11.5 d'Ingress Nginx Controller (Ingress-Nginx) publiées lundi. Une cinquième faille, répertoriée sous le nom de CVE-2025-24513, a également été identifiée et corrigée dans les mêmes versions.

Un risque d'injection de configuration non authentifiée

L'une des fonctions de Kubernetes exposant les charges de travail à l'internet est appelée ingress et permet aux administrateurs d'acheminer le trafic entrant vers différents services sur la base de règles définies via l'API de Kubernetes. Il existe de nombreux contrôleurs d'ingress, mais Ingress-Nginx, qui s'appuie sur le serveur web et le proxy inverse Nginx, est l'un des plus populaires et est couramment utilisé comme exemple dans la documentation officielle. Selon Wiz, plus de 41 % des clusters Kubernetes ouverts sur Internet utilisent Ingress-Nginx.

Le contrôleur Ingress-Nginx sert à traiter les objets entrants, créer des configurations Nginx correspondantes basées sur ces objets, puis les valider et les utiliser pour décider comment et où acheminer les requêtes. Les failles découvertes par Wiz donnent à un attaquant la capacité d'injecter des paramètres de configuration qui, une fois validés, entraînent l'exécution d'un code arbitraire par le validateur Nginx. « Le traitement approprié de ces paramètres de configuration Nginx est crucial, car Ingress-Nginx doit proposer aux utilisateurs une flexibilité significative tout en les empêchant de tromper accidentellement ou intentionnellement Nginx pour qu'il fasse des choses qu'il ne devrait pas faire », a déclaré l'équipe Kubernetes dans un billet de blog. Le problème est que le pod Ingress-Nginx dispose de privilèges élevés et d'une accessibilité illimitée au réseau. Plus important encore, il a accès à tous les secrets du cluster par défaut, ce qui signifie qu'un attaquant réussissant à exécuter du code dans ce pod peut dérober ces secrets et prendre le contrôle de l'ensemble du cluster.

La vulnérabilité CVE-2025-1974 est la plus grave et affiche un score CVSS de 9,8. Elle propose à toute personne ayant accès au réseau Pod d'exploiter les autres vulnérabilités d'injection de configuration, qui nécessiteraient autrement des actions privilégiées pour être exploitées. « Combinée aux autres trous de sécurité d'aujourd'hui, la CVE-2025-1974 signifie que n'importe qui sur le réseau Pod a de bonnes chances de prendre le contrôle de votre cluster Kubernetes, sans avoir besoin d'informations d'identification ou d'accès administratif », ont averti les responsables de Kubernetes. « Dans de nombreux scénarios courants, le réseau Pod est accessible à toutes les charges de travail dans votre VPC, ou même à toute personne connectée à votre réseau d'entreprise ! C'est une situation très grave. »

Deux façons d'atténuer les faiblesses

En termes de remédiation, la meilleure solution consiste à mettre à jour le composant Ingress-Nginx vers l'une des versions corrigées. Les administrateurs peuvent déterminer s'il est utilisé dans leurs clusters en tapant : kubectl get pods -all-namespaces -selector app.kubernetes.io/name=ingress-Nginx Dans les situations où une mise à niveau immédiate de la version n'est pas possible, les administrateurs peuvent réduire les risques en supprimant la configuration ValidatingWebhookConfiguration appelée ingress-Nginx-admission et en supprimant l'argument -validating-webhook du Deployment ou DaemonSet du conteneur ingress-Nginx-controller. Si ingress-Nginx a été installé à l'aide de Helm, il peut être réinstallé avec controller.admissionWebhooks.enabled=false. Cela atténuera CVE-2025-1974 en particulier, ce qui rend beaucoup plus facile l'exploitation des autres vulnérabilités sans authentification. Cependant, le contrôleur de validation ne devrait pas rester désactivé pendant une longue période car il fournit des garanties contre les mauvaises configurations d'entrée pour les utilisateurs légitimes.