Gravité : CRITIQUE (CVSS 9.8) | Action requise : Mettez à jour immédiatement Plusieurs vulnérabilités affectant le contrôleur NGINX Ingress permettent à des attaquants disposant d'un accès au réseau des pods d'exécuter du code arbitraire et d'accéder à tous les Secrets du cluster, sans avoir besoin d'identifiants ni de privilèges administratifs. Si votre cluster ACK exécute un contrôleur NGINX Ingress avec le webhook d'admission activé, considérez cette situation comme une urgence et agissez dès maintenant.
Suis-je concerné ?
Utilisez l'arbre de décision suivant pour déterminer si votre cluster est exposé au risque.
Étape 1 : Vérifiez si le contrôleur NGINX Ingress est installé
kubectl get pods -n kube-system --selector app=ingress-nginxSi aucun pod n'est renvoyé, votre cluster ne dispose pas du contrôleur NGINX Ingress et n'est pas affecté. Aucune action supplémentaire n'est nécessaire.
Si des pods sont renvoyés, passez à l'étape 2.
Étape 2 : Vérifiez la version en cours d'exécution
Versions du contrôleur NGINX Ingress concernées :
Toutes les versions antérieures à v1.11.5
v1.12.0
Si votre cluster exécute la version v1.11.5, v1.12.1 ou toute version ultérieure, vous utilisez déjà une version corrigée. Aucune action supplémentaire n'est nécessaire.
Pour déterminer la version installée, consultez Comment vérifier votre méthode d'installation et votre version.
Étape 3 : Vérifiez si le webhook d'admission est activé
Les clusters dont le webhook d'admission est désactivé ne sont pas affectés par la vulnérabilité la plus critique (CVE-2025-1974). Toutefois, les vulnérabilités d'injection basées sur les annotations (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) s'appliquent toujours si un utilisateur dispose d'autorisations d'écriture sur les ressources Ingress. Nous vous recommandons de procéder à la mise à niveau.
-
Installation via les modules complémentaires : Exécutez la commande suivante. Si la ressource est introuvable, le webhook d'admission est désactivé.
kubectl get validatingwebhookconfigurations ingress-nginx-admission Installation via le Marketplace : Consultez les informations de base de l'application concernée et vérifiez l'existence d'une ressource de type
ValidatingWebhookConfiguration.
Résumé
|
Condition |
Niveau de risque |
|
Contrôleur NGINX Ingress non installé |
Non concerné |
|
Installé, version >= v1.11.5 (1.11.x) ou >= v1.12.1 (1.12.x) |
Non concerné (déjà corrigé) |
|
Installé, version concernée, webhook d'admission désactivé |
Risque réduit (mise à niveau recommandée) |
|
Installé, version concernée, webhook d'admission activé |
Concerné – Agissez immédiatement |
Comment vérifier votre méthode d'installation et votre version
Le contrôleur NGINX Ingress peut être installé dans les clusters ACK via deux méthodes : la page Add-ons ou le Marketplace (chart Helm). Les étapes de correction diffèrent selon la méthode utilisée.
Installation via la page Add-ons
Méthode 1 : Vérification depuis la page Add-ons
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, localisez le cluster que vous souhaitez gérer et cliquez sur son nom. Dans le volet de navigation de gauche, cliquez sur Add-ons.
Sur la page Add-ons, recherchez et localisez Nginx Ingress Controller, puis vérifiez sur la carte du composant s'il est installé ainsi que sa version actuelle.
Méthode 2 : Requête via kubectl
kubectl get pods -n kube-system --selector app=ingress-nginxInstallation via le Marketplace (chart Helm)
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, localisez le cluster que vous souhaitez gérer et cliquez sur son nom. Dans le volet de navigation de gauche, choisissez Applications > Helm.
Dans la liste Helm, vérifiez si
ack-ingress-nginxouack-ingress-nginx-v1figure dans la colonne Chart Name, où Application Version indique la version actuelle du composant NGINX Ingress controller.
Détails des vulnérabilités
La communauté Kubernetes a divulgué cinq vulnérabilités de sécurité affectant le contrôleur NGINX Ingress. Quatre d'entre elles permettent aux attaquants d'injecter des configurations malveillantes via des annotations Ingress falsifiées. La vulnérabilité la plus critique, CVE-2025-1974, permet l'exécution de code non authentifié par toute entité disposant d'un accès au réseau des pods, contournant ainsi entièrement le webhook d'admission.
Concrètement, toute charge de travail s'exécutant dans le réseau des pods de votre cluster — ou toute entité ayant un accès réseau au point de terminaison du contrôleur d'admission — peut exploiter ces vulnérabilités pour exécuter du code arbitraire au sein du contrôleur NGINX Ingress et récupérer tous les Secrets du cluster. Dans de nombreux scénarios courants, le réseau des pods est accessible à toutes les charges de travail de votre VPC cloud, voire à toute personne connectée à votre réseau d'entreprise. Cela signifie que des Secrets tels que les certificats TLS, les identifiants API et autres données sensibles stockées dans Kubernetes peuvent être exposés.
|
ID CVE |
Gravité |
Score CVSS v3.1 |
Description |
Risque |
Référence |
|
Élevée |
Les attaquants disposant d'autorisations d'écriture sur les ressources Ingress peuvent exploiter l'annotation |
Les attaquants peuvent exécuter du code arbitraire dans le contexte du contrôleur NGINX Ingress et obtenir ensuite les Secrets de l'ensemble du cluster. |
|||
|
Élevée |
Les attaquants disposant d'autorisations d'écriture sur les ressources Ingress peuvent exploiter les annotations |
Les attaquants peuvent exécuter du code arbitraire dans le contexte du contrôleur NGINX Ingress et obtenir ensuite les Secrets de l'ensemble du cluster. |
|||
|
Critique |
Les attaquants disposant d'un accès au réseau des pods peuvent contourner le webhook d'admission pour injecter des configurations. |
Les attaquants peuvent exécuter du code arbitraire dans le contexte du contrôleur NGINX Ingress et obtenir ensuite les Secrets de l'ensemble du cluster. |
|||
|
Élevée |
Les attaquants disposant d'autorisations d'écriture sur les ressources Ingress peuvent exploiter l'annotation |
Les attaquants peuvent exécuter du code arbitraire dans le contexte du contrôleur NGINX Ingress et obtenir ensuite les Secrets de l'ensemble du cluster. |
|||
|
Moyenne |
Le contrôleur NGINX Ingress ne valide ni ne filtre correctement les données d'entrée soumises par les utilisateurs disposant d'autorisations d'écriture sur les ressources Ingress. Les attaquants peuvent exploiter cette vulnérabilité pour créer des requêtes malveillantes et injecter des données non autorisées dans le processus de génération du fichier de configuration. |
Des vulnérabilités de traversée de répertoire au sein du conteneur peuvent être déclenchées. Cette vulnérabilité peut provoquer un déni de service (DoS) ou, combinée à d'autres vulnérabilités, entraîner la fuite d'instances limitées de Secrets dans le cluster. |
Mesures d'atténuation provisoires
Si vous ne pouvez pas effectuer la mise à niveau immédiatement, désactivez le webhook d'admission afin de bloquer le vecteur d'attaque le plus critique (CVE-2025-1974). Il s'agit d'une mesure temporaire : vous devez néanmoins mettre à niveau vers une version corrigée dès que possible.
Pour les clusters dont le contrôleur NGINX Ingress est installé via la page Add-ons
Sur la page Add-ons du cluster cible, localisez le composant Nginx Ingress Controller et désactivez manuellement la fonctionnalité de webhook d'admission. Pour plus de détails, consultez Gérer le contrôleur NGINX Ingress.
Pour les clusters dont le contrôleur NGINX Ingress est installé via le Marketplace
Supprimez manuellement le webhook d'admission associé afin de réduire le risque :
kubectl delete validatingwebhookconfigurations ingress-nginx-admissionLa désactivation ou la suppression du webhook d'admission supprime un mécanisme de pré-validation des configurations Ingress. Bien que cela atténue la vulnérabilité, les configurations Ingress invalides ne seront plus rejetées avant leur application. Réactivez le webhook d'admission après la mise à niveau vers une version corrigée.
Correction : Mise à niveau vers une version corrigée
La communauté a corrigé les cinq vulnérabilités dans les versions suivantes du contrôleur NGINX Ingress :
v1.11.5
v1.12.1
Effectuez la mise à niveau vers la version v1.11.5 ou ultérieure (pour la branche de publication 1,11.x) ou vers la version v1.12.1 ou ultérieure (pour la branche de publication 1,12.x) pendant les heures creuses.
Gestion des modules complémentaires
Si ce n'est pas déjà fait, désactivez le webhook d'admission comme décrit dans la section Mesures d'atténuation provisoires afin de réduire le risque pendant la préparation de la mise à niveau.
Mettez à niveau le composant NGINX Ingress controller vers la version v1.11.5 ou ultérieure. Consultez les notes de version du contrôleur NGINX Ingress pour obtenir des détails sur les versions, et suivez les instructions de la rubrique Mettre à jour le contrôleur NGINX Ingress pour effectuer la mise à niveau.
Une fois la mise à niveau terminée, réactivez le webhook d'admission.
Après la mise à jour, assurez-vous de réactiver la fonctionnalité de webhook d'admission. Cette fonctionnalité sert de mécanisme de pré-validation des configurations Ingress et permet d'améliorer efficacement la fiabilité et la stabilité du service. Avant que la création ou la mise à jour de votre configuration Ingress ne prenne effet, le webhook d'admission vous alertera en cas d'erreurs dans la configuration Ingress, vous permettant ainsi de prévenir les problèmes.
Marketplace
Si ce n'est pas déjà fait, supprimez manuellement le webhook d'admission comme décrit dans la section Mesures d'atténuation provisoires afin de réduire le risque pendant la préparation de la mise à niveau.
Consultez les notes de version du composant sur la page Marketplace ou la page Helm de la console, et mettez à jour ack-ingress-nginx sur la page Marketplace vers la version v1.11.5 ou ultérieure pendant les heures creuses.
Une fois la mise à niveau terminée, vérifiez que le webhook d'admission a été recréé dans le cadre du déploiement mis à jour du chart Helm. Si ce n'est pas le cas, réactivez-le manuellement.
Références des correctifs
La communauté a résolu chaque vulnérabilité dans les commits suivants (tous faisant partie de la PR #13068) :
|
CVE |
Commit |
|
CVE-2025-1097 |
ingress-nginx main@06c992a |
|
CVE-2025-1098 |
ingress-nginx main@2e9f373 |
|
CVE-2025-1974 |
ingress-nginx main@0ccf4ca |
|
CVE-2025-24513 |
ingress-nginx main@cbc1590 |
|
CVE-2025-24514 |
ingress-nginx main@ab470eb |
FAQ
Q : Mon cluster ne dispose pas du contrôleur NGINX Ingress. Suis-je concerné ?
Non. Les clusters ne disposant pas du contrôleur NGINX Ingress ne sont affectés par aucune de ces vulnérabilités. Aucune action n'est nécessaire.
Q : J'ai désactivé le webhook d'admission. Suis-je toujours à risque ?
La désactivation du webhook d'admission bloque la vulnérabilité la plus critique (CVE-2025-1974, CVSS 9.8). Cependant, les vulnérabilités d'injection basées sur les annotations (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) peuvent toujours être exploitées par des attaquants disposant d'autorisations d'écriture sur les ressources Ingress, indépendamment de la configuration du webhook. Nous vous recommandons de mettre à niveau vers une version corrigée.
Q : Dois-je réactiver le webhook d'admission après la mise à niveau ?
Oui. Le webhook d'admission sert de mécanisme de pré-validation des configurations Ingress. Il détecte et rejette les configurations invalides avant qu'elles ne prennent effet, vous aidant ainsi à prévenir les interruptions de service. Réactivez-le systématiquement après la mise à niveau vers une version corrigée.
Q : Quelle est la différence entre les chemins d'installation Add-ons et Marketplace ?
Le contrôleur NGINX Ingress peut être installé dans ACK via la page Add-ons (géré par le cycle de vie des modules complémentaires d'ACK) ou via le Marketplace sous forme de chart Helm. Les étapes de correction diffèrent légèrement : les utilisateurs d'Add-ons désactivent le webhook via l'interface utilisateur de la console, tandis que les utilisateurs du Marketplace suppriment directement la ressource ValidatingWebhookConfiguration. Les deux méthodes nécessitent une mise à niveau vers la version v1.11.5 ou ultérieure.