How to fix vulnerabilities CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, and CVE-2025-24514 - Container Service for Kubernetes

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 sans délai.

Suis-je concerné ?

Utilisez l'arbre de décision suivant pour déterminer si votre cluster est exposé.

Étape 1 : Vérifiez si le contrôleur NGINX Ingress est installé

kubectl get pods -n kube-system --selector app=ingress-nginx

Si 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 affectées :

Toutes les versions antérieures à la 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 la rubrique 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) restent applicables si un utilisateur dispose d'autorisations d'écriture sur les ressources Ingress. Nous vous recommandons de procéder à la mise à jour.

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 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 affecté
| |
Installé, version >= v1,11.5 (1,11.x) ou >= v1,12.1 (1,12.x)
|
Non affecté (déjà corrigé)
| |
Installé, version affectée, webhook d'admission désactivé
|
Risque réduit (mise à jour recommandée)
| |
Installé, version affectée, webhook d'admission activé
|
**Affecté — 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 par deux voies : la page Add-ons ou Marketplace (chart Helm). Les étapes de correction diffèrent selon la méthode utilisée.

Installé via la page Add-ons

Méthode 1 : Vérification sur la page Add-ons

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, repérez le cluster à gérer et cliquez sur son nom. Dans le volet de navigation de gauche, cliquez sur Add-ons.
Sur la page Add-ons, recherchez 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-nginx

Installé via Marketplace (chart Helm)

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, repérez le cluster à 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-nginx ou ack-ingress-nginx-v1 figure dans la colonne Chart Name. La valeur indiquée dans la colonne Application Version correspond à 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 conçues à cet effet. 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**
| | --- | --- | --- | --- | --- | --- | |
[CVE-2025-1097](https://github.com/advisories/GHSA-823x-fv5p-h7hw)
|
Élevée
|
[8,8](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
|
Les attaquants disposant d'autorisations d'écriture sur les ressources Ingress peuvent exploiter l'annotation `auth-tls-match-cn` fournie par la communauté NGINX Ingress pour injecter des configurations malveillantes.
|
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.
|
[#131007](https://github.com/kubernetes/kubernetes/issues/131007)
| |
[CVE-2025-1098](https://github.com/advisories/GHSA-vg63-w3p9-jc9m)
|
Élevée
|
[8,8](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
|
Les attaquants disposant d'autorisations d'écriture sur les ressources Ingress peuvent exploiter les annotations `mirror-target` et `mirror-host` fournies par la communauté NGINX Ingress pour injecter des configurations malveillantes.
|
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.
|
[#131008](https://github.com/kubernetes/kubernetes/issues/131008)
| |
[CVE-2025-1974](https://github.com/advisories/GHSA-mgvx-rpfc-9mpv)
|
Critique
|
[9,8](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
|
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.
|
[#131009](https://github.com/kubernetes/kubernetes/issues/131009)
| |
[CVE-2025-24514](https://github.com/advisories/GHSA-fwwp-xcxw-39vq)
|
Élevée
|
[8,8](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
|
Les attaquants disposant d'autorisations d'écriture sur les ressources Ingress peuvent exploiter l'annotation `auth-url` fournie par la communauté NGINX Ingress pour injecter des configurations malveillantes.
|
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.
|
[#131006](https://github.com/kubernetes/kubernetes/issues/131006)
| |
[CVE-2025-24513](https://github.com/advisories/GHSA-242m-6h72-7hgp)
|
Moyenne
|
[4,8](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L)
|
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 élaborer des requêtes malveillantes et injecter des données non autorisées dans le chemin de génération du fichier de configuration.
|
Des vulnérabilités de traversal 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.
|
[#131005](https://github.com/kubernetes/kubernetes/issues/131005)
|

Mesures d'atténuation provisoires

Si vous ne pouvez pas effectuer la mise à jour immédiatement, désactivez le webhook d'admission pour bloquer le vecteur d'attaque le plus critique (CVE-2025-1974). Il s'agit d'une mesure temporaire : vous devez néanmoins mettre à jour 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 la rubrique Gérer le contrôleur NGINX Ingress.

Pour les clusters dont le contrôleur NGINX Ingress est installé via Marketplace

Supprimez manuellement le webhook d'admission associé afin de réduire le risque :

kubectl delete validatingwebhookconfigurations ingress-nginx-admission

Important

La désactivation ou la suppression du webhook d'admission retire un mécanisme de pré-validation des configurations Ingress. Bien que cette action 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 avoir effectué la mise à jour vers une version corrigée.

Correction : Mise à jour 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 à jour 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 à jour.
Mettez à jour 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 les détails des versions, et suivez les instructions de la rubrique Mettre à jour le contrôleur NGINX Ingress pour effectuer la mise à jour.
Une fois la mise à jour terminée, réactivez le webhook d'admission.

Important

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 améliore 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, ce qui vous permettra 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 à jour.
Consultez les notes de version du composant sur la page Marketplace ou 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 à jour terminée, vérifiez que le webhook d'admission a été recréé dans le cadre du déploiement du chart Helm mis à jour. Si ce n'est pas le cas, réactivez-le manuellement.

Références des correctifs

La communauté a corrigé chaque vulnérabilité dans les commits suivants (tous faisant partie de la PR #13068) :

|
**CVE**
|
**Commit**
| | --- | --- | |
CVE-2025-1097
|
ingress-nginx [main@06c992a](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/06c992abd8eef9710359a236c443c613d29fdfad)
| |
CVE-2025-1098
|
ingress-nginx [main@2e9f373](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/2e9f37380afb7853fa6daa1c3e6659550aadfd90)
| |
CVE-2025-1974
|
ingress-nginx [main@0ccf4ca](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/0ccf4caaadec919680c455d221e53d97970d527d)
| |
CVE-2025-24513
|
ingress-nginx [main@cbc1590](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/cbc159094f6d1b1bf8cf1761eb119138d1f95df1)
| |
CVE-2025-24514
|
ingress-nginx [main@ab470eb](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/ab470eb920924d62a197ebddd8a4cc3031a77ddf)
|

FAQ

Q : Mon cluster ne dispose pas du contrôleur NGINX Ingress. Suis-je concerné ?

Non. Les clusters sans contrôleur NGINX Ingress installé 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). Toutefois, 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 à jour vers une version corrigée.

Q : Dois-je réactiver le webhook d'admission après la mise à jour ?

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, ce qui vous aide à prévenir les interruptions de service. Réactivez-le systématiquement après avoir effectué la mise à jour vers une version corrigée.

Q : Quelle est la différence entre les voies 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 Marketplace en tant que 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 de Marketplace suppriment directement la ressource ValidatingWebhookConfiguration. Les deux voies nécessitent une mise à jour vers la version v1,11.5 ou ultérieure.