CVE-2025-1974 — IngressNightmare (ingress-nginx)

Introduction

Ce document présente une recherche sur la vulnérabilité CVE-2025-1974 affectant le composant ingress-nginx (validating admission controller) pour Kubernetes.
CVE-2025-1974 est une vulnérabilité critique (CVSS 3.1 9.8) constituant une Remote Code Execution (RCE) non authentifiée dans le contexte du processus ingress-nginx. Lors de l'exécution de l'attaque, un attaquant disposant d'un accès au réseau des pods (ou d'un moyen de délivrer un AdmissionReview au validating webhook) peut parvenir à exécuter du code arbitraire dans le pod du contrôleur, ce qui mène potentiellement à la divulgation de Secrets et à la prise de contrôle du cluster.

Ingress-nginx est l'un des contrôleurs Ingress les plus répandus dans Kubernetes (les estimations indiquaient une utilisation dans des dizaines de pour cent des clusters), donc l'impact pratique de la vulnérabilité est très élevé. La description, l'analyse technique et les recommandations officielles de correctifs ont été publiées par Kubernetes, les chercheurs de Wiz et plusieurs blogs de fournisseurs.

Objectif du rapport

Analyser pas à pas CVE-2025-1974 et préparer les éléments nécessaires au write-up :

Collecte et structuration des matériaux. Rassembler les advisories officiels, les write-ups de recherche et les analyses des fournisseurs ; mettre en évidence les détails techniques clés et les pistes de PoC.
Comprendre l'essence de la vulnérabilité et son impact. Expliquer la root cause, la chaîne d'attaque et les conséquences possibles (RCE → disclosure of Secrets → cluster takeover).
Déterminer le CPE et les conditions de configuration. Énumérer les versions/paquets et les configurations Kubernetes/ingress-nginx pour lesquelles la vulnérabilité est pertinente.
Fournir des recommandations pour des tests sécurisés en laboratoire et pour minimiser les risques lors d'une vérification à grande échelle.

⚠️ Avertissement

Cette recherche est menée exclusivement à des fins éducatives et éthiques et s'adresse à des environnements de test/contrôlés.
En aucun cas ne lancez d'exploits/PoC contre des clusters tiers ou des instances publiquement accessibles sans l'autorisation écrite du propriétaire. La publication ouverte d'un PoC entièrement opérationnel « weaponized » augmente fortement le risque d'abus — il est préférable de fournir dans la partie publique un safe-PoC et une méthodologie. (Les advisories officiels et les fournisseurs soulignent également la prudence lors de la diffusion d'exploits).

CPE et conditions de configuration

cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — versions vulnérables d'ingress-nginx (les advisories indiquent des versions spécifiques ; mettez à jour les valeurs lors de la publication finale).
Fournisseurs/distributions incluant le contrôleur vulnérable :
- Les distributions RKE2 / Rancher avec ingress-nginx antérieur aux versions de correctif indiquées.
- Les versions de Harvester utilisant un ingress-nginx vulnérable (la base de connaissances du fournisseur contient les builds affectés spécifiques).
- Les clusters personnalisés où ingress-nginx est installé séparément (chart/manifest Helm) — vérifier les versions du chart/image.

Conditions de configuration pour lesquelles la vulnérabilité est pertinente :

Version vulnérable d'ingress-nginx (antérieure à la version/correctif indiqué dans les advisories). Voir les numéros de version exacts dans NVD et les advisories des fournisseurs.
Validating admission webhook accessible depuis l'extérieur du réseau des pods — si le webhook est accessible depuis l'extérieur (par exemple, endpoint public, fournisseur ayant exposé le service par erreur), l'exploit peut être exécuté à distance. Wiz et d'autres chercheurs ont signalé de nombreux cas d'exposition publique.
Absence de NetworkPolicy / d'isolation du réseau des pods : si un attaquant peut envoyer des requêtes depuis un pod quelconque vers le réseau du cluster (pod compromis), cela suffit pour l'exploitation.
Absence de validations/ACL supplémentaires avant l'admission controller : des filtres supplémentaires / une authentification par ingress-proxy peuvent réduire le risque.
Présence dans le conteneur ingress-nginx d'un compte de service avec des droits étendus et un accès aux Secrets — par défaut, le contrôleur monte souvent un serviceAccount avec des droits étendus ; cela augmente l'impact en cas d'exploitation réussie.

Détails de la vulnérabilité

Résumé succinct.
La vulnérabilité a été découverte dans le composant Validating Admission Controller du contrôleur Ingress-NGINX et est liée à la manière dont ce composant génère et vérifie la configuration temporaire de NGINX à partir des Ingress / AdmissionReview entrants. Lors du traitement, le contrôleur génère nginx.conf et lance la vérification de la configuration (nginx -t). En raison d'une sanitisation insuffisante des champs Ingress/AdmissionReview, un attaquant peut injecter des fragments spécialement préparés qui se retrouvent dans la configuration générée et entraînent l'exécution de commandes dans le processus du contrôleur — c'est-à-dire une exécution de code à distance (RCE) dans le pod ingress-nginx.

Points techniques principaux

Point d'entrée. Les objets AdmissionReview/Ingress entrants, acceptés par le validating webhook du contrôleur, deviennent les données sources pour la génération de la configuration NGINX (y compris les champs d'annotations, les paramètres backend, etc.).
Mécanisme d'exploitation. Un Ingress malveillant ou un AdmissionReview direct peut injecter des chaînes contrôlées dans les modèles/fragments de configuration. Lors de la vérification/du chargement de ce nginx.conf, le processus de vérification (nginx -t) et les opérations ultérieures sur le fichier de configuration peuvent conduire à l'exécution de code arbitraire, à l'écriture/exécution de fichiers ou au lancement de commandes dans le contexte du contrôleur.
Conditions requises. Pour une exploitation réussie, il faut : une version vulnérable d'ingress-nginx ; la possibilité de délivrer un AdmissionReview au validating webhook (accès depuis le réseau des pods ou accès réseau direct) ; l'absence de mesures compensatoires — NetworkPolicy, restrictions RBAC ou authentification supplémentaire du webhook. Dans certains scénarios, le contournement des droits Create/Update est possible en envoyant un AdmissionReview forgé directement au webhook.

admission

En quoi c'est dangereux — conséquences de l'exploitation

Une exploitation réussie permet l'exécution de code dans le conteneur ingress-nginx, ce qui permet généralement :

d'obtenir le jeton du serviceAccount du contrôleur et d'accéder à l'API Kubernetes ;
de lire les Secrets et d'autres informations confidentielles dans les namespace accessibles ;
de créer/modifier des ressources du cluster et d'étendre l'accès (escalade de privilèges, lateral movement) ;
dans certains cas — la prise de contrôle complète du cluster.

Observations comportementales et de détection

En fonctionnement normal, il n'y a généralement pas de flux de requêtes vers l'Admission Controller — le validating webhook sert de composant interne fonctionnant au sein du cluster. Pendant l'exploitation, une anomalie est observée : sur la carte réseau (par exemple, Luntry), l'apparition de connexions entrantes vers ingress-nginx-controller-admission et le service ingress-nginx-controller depuis des sources non standard (dans les rapports — depuis des conteneurs de type alpine), ce qui ne devrait pas se produire en fonctionnement normal.
L'analyse de la carte réseau du cluster donne une vision des interactions entre les microservices ; en sélectionnant le Deployment ingress-nginx dans le namespace, on peut voir les connexions entrantes/sortantes. L'apparition de connexions entrantes vers l'admission-endpoint au moment de l'attaque est un indicateur clair de compromission.
Pour détecter les tentatives d'exploitation, il est utile de surveiller : les requêtes POST vers le validating webhook, la création d'objets Ingress atypiques, les appels nginx -t et les redémarrages soudains du contrôleur, ainsi que les opérations inattendues d'écriture de fichiers par le processus ingress-nginx.

Contexte : qu'est-ce que le contrôleur Ingress NGINX et pourquoi est-il important

Ingress-NGINX est l'un des contrôleurs Ingress les plus utilisés dans Kubernetes (largement employé pour organiser l'accès externe aux services). Le contrôleur agit comme un proxy inverse : il reçoit le trafic externe et le proxifie vers les Service/Pod correspondants sur la base d'un ensemble de règles Ingress. Le projet Ingress-NGINX est très populaire et détient une part d'installation significative dans les clusters accessibles sur Internet.

Ingress-NGINX est présenté dans la documentation Kubernetes comme un exemple de référence de contrôleur Ingress. Selon les estimations, une part importante des clusters ouverts l'utilisent ; certaines études indiquent qu'environ 41 % des clusters publiquement accessibles utilisent Ingress-NGINX. C'est précisément en raison de sa large diffusion et de son rôle central dans le routage du trafic que les vulnérabilités de ce composant ont un impact pratique élevé.

Pourquoi le validating webhook devient un vecteur d'attaque pratique

Par défaut, le validating webhook du contrôleur est accessible dans l'espace réseau de Kubernetes et ne nécessite souvent pas d'authentification supplémentaire lors de l'accès à son adresse (par exemple, validate.nginx.ingress.kubernetes.io). Cela le rend facile à atteindre depuis l'intérieur du cluster.
La combinaison : large diffusion du contrôleur + accessibilité réseau + droits potentiellement étendus du compte de service = combinaison critique offrant une voie efficace vers la compromission.
Dans la pratique réelle, obtenir un « premier point d'entrée » dans le cluster n'est pas si difficile : les applications contiennent souvent des vulnérabilités conduisant à la compromission d'un conteneur individuel ; ensuite, l'attaquant depuis ce conteneur peut contacter les webhooks internes. De plus, les vulnérabilités exploitables de type SSRF dans les applications web sont souvent utilisées pour initier des requêtes vers le réseau du cluster et solliciter ces webhooks.

Récapitulatif de la chaîne d'exploitation (de manière concise)

L'attaquant obtient la possibilité d'envoyer des requêtes dans le réseau des pods ou d'accéder directement au validating webhook.
Un Ingress / AdmissionReview spécialement forgé est créé, où certains champs contiennent des chaînes malveillantes n'ayant pas subi de filtrage approprié.
Le contrôleur génère nginx.conf sur la base de ces données d'entrée et exécute nginx -t / d'autres opérations de vérification.
Les fragments injectés conduisent à l'exécution de commandes/scripts ou à l'écriture/exécution de fichiers dans le contexte du processus du contrôleur.
Une fois l'exécution obtenue, l'attaquant extrait le jeton du serviceAccount, accède à l'API Kubernetes et poursuit le déplacement latéral et l'escalade de privilèges dans le cluster.

Remarques sur la compatibilité avec d'autres vulnérabilités

Ces vulnérabilités sont particulièrement dangereuses en combinaison avec d'autres défauts : un pod compromis (ou une SSRF dans une application publique) + un validating webhook exposé donne une forte probabilité de compromission totale. Par conséquent, l'analyse des incidents doit prendre en compte la chaîne de dépendances et les vecteurs potentiels, et pas seulement la version d'ingress-nginx.

CVE-2025-1974

Populaires