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 :

1. 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.
2. 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).
3. 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.
4. 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 :

1. 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.
2. 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.
3. 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.
4. Absence de validations/ACL supplémentaires avant l'admission controller : des filtres supplémentaires / une authentification par ingress-proxy peuvent réduire le risque.
5. 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.

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.