Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

Publié le 26 mars 2025
Ingress Nightmare — CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974. Sur un cluster Kubernetes utilisant Ingress NGINX, un attaquant capable d’atteindre le webhook d’admission peut exécuter du code arbitraire et, par effet de cascade, prendre le contrôle du cluster.

​
Le périmètre

La faille touche Ingress NGINX Controller (à ne pas confondre avec NGINX Ingress Controller, le projet maintenu par F5/NGINX, qui est un produit différent). Versions vulnérables :
  • toutes les versions < v1.11.0
  • v1.11.0 à v1.11.4
  • v1.12.0
Vérification rapide : 
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{.items[*].spec.containers[*].image}'

​
Comment l’attaque fonctionne

Quand vous installez Ingress NGINX, un admission controller est déployé à l’intérieur du cluster. Son rôle : valider les objets Ingress avant qu’ils ne soient appliqués à NGINX. Le problème : ce webhook est joignable sur le réseau du cluster, sans authentification, par défaut. L’attaquant qui peut atteindre ce webhook (depuis un pod compromis, un service interne mal isolé, ou parfois directement depuis l’extérieur si la Service est exposée) envoie un objet Ingress malveillant. Le webhook traite l’objet, en construit une configuration NGINX et la valide en exécutant le binaire NGINX… qui interprète à ce moment-là la charge injectée. RCE dans le pod du contrôleur. Et là, c’est la cascade. Le pod du contrôleur a souvent les droits de lire les Secrets de tous les namespaces (parce qu’il monte les certificats TLS). Une fois RCE acquise, l’attaquant lit donc tous les secrets du cluster — credentials internes, tokens cloud, clés API. Cluster takeover.

​
Patcher

Mettez à jour Ingress NGINX Controller vers la dernière version stable disponible — au-delà des versions listées comme vulnérables. Suivez la procédure habituelle Helm/manifests selon votre installation.

​
Si vous ne pouvez pas patcher tout de suite

Deux mesures de réduction de surface, à appliquer en attendant :

​
1. Restreindre l’accès réseau au webhook

Une NetworkPolicy qui n’autorise que l’API server Kubernetes à parler au webhook d’admission : 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-nginx-admission-only-apiserver
  namespace: ingress-nginx
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/component: admission-webhook
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: <CIDR de l'API server>
      ports:
        - port: 8443
          protocol: TCP
Adaptez le CIDR à votre cluster.

​
2. Désactiver temporairement le webhook d’admission

Si la NetworkPolicy n’est pas tenable et que vous patcher dans la foulée, vous pouvez désactiver le composant admission. Avec Helm : 
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --reuse-values \
  --set controller.admissionWebhooks.enabled=false
Vous perdez la validation des objets Ingress à l’admission — donc la sécurité préventive sur les configurations malformées — mais vous fermez la voie d’attaque le temps du patch.

​
Conclusion

C’est une chaîne RCE → vol de secrets → takeover qui n’exige pas d’authentification, sur un composant que beaucoup de clusters exposent par défaut. Un PoC est public. Patchez, et profitez-en pour vérifier les NetworkPolicy autour de tous vos webhooks d’admission. Pour toute question, ouvrez un ticket depuis votre espace client OnetSolutions.