Une vulnérabilité récemment divulguée dans ingress-nginx pourrait permettre à des attaquants authentifiés d’exécuter du code et d’accéder aux Secrets Kubernetes dans les clusters concernés.
La vulnérabilité pourrait « … entraîner l’exécution de code arbitraire dans le contexte du contrôleur ingress-nginx et la divulgation des Secrets auxquels le contrôleur a accès », ont déclaré des chercheurs en Kubernetes.
Au cœur de la vulnérabilité de sécurité d’Ingress-Nginx
Les contrôleurs Ingress se trouvent à la périphérie des clusters Kubernetes, où ils gèrent le trafic entrant et acheminent les requêtes vers les services internes.
Comme ingress-nginx fonctionne souvent avec des privilèges élevés, les vulnérabilités de ce composant peuvent avoir un impact disproportionné.
Dans de nombreux déploiements par défaut, le contrôleur ingress-nginx dispose de l’autorisation de lire les Secrets dans l’ensemble du cluster, ce qui signifie qu’une seule exploitation réussie pourrait exposer des identifiants, des jetons ou des données de configuration utilisés par plusieurs applications.
La vulnérabilité, répertoriée sous le nom de CVE-2026-24512, est un problème d’injection de configuration lié au rules.http.paths.path des ressources Ingress Kubernetes.
Une validation incorrecte de ce champ permet à un attaquant de fournir des valeurs spécialement conçues, qui sont injectées directement dans la configuration nginx générée par ingress-nginx.
Ce comportement remet en cause l’hypothèse selon laquelle les définitions Ingress sont traduites de manière sûre en configuration serveur.
Un attaquant autorisé à créer ou à modifier des ressources Ingress peut exploiter cette faille pour injecter des directives nginx arbitraires.
En pratique, cette faille permet d’exécuter du code arbitraire dans le contexte du contrôleur ingress-nginx et donc d’exécuter des commandes au sein du pod du contrôleur.
Bien qu’une authentification soit requise, le niveau d’accès nécessaire est relativement faible, ce qui accroît les risques dans les environnements où des développeurs ou des comptes de service sont autorisés à gérer les ressources Ingress.
La vulnérabilité est exploitable à distance via le réseau, présente une faible complexité d’attaque et ne nécessite aucune interaction de l’utilisateur.
Outre l’exécution de code, une exploitation réussie peut entraîner un accès non autorisé aux Secrets Kubernetes que le contrôleur est autorisé à lire.
Comme ingress-nginx dispose souvent par défaut d’un accès aux Secrets à l’échelle du cluster, l’ampleur potentielle des dégâts dépasse un seul espace de noms et peut affecter l’ensemble du cluster.
CVE-2026-24512 affecte plusieurs versions d’ingress-nginx, notamment toutes les versions antérieures à v1.13.7 et v1.14.3. La vulnérabilité a été corrigée dans les versions 1.13.7, 1.14.3 et toutes les versions ultérieures d’ingress-nginx.
Au moment de la divulgation, rien n’indiquait que la vulnérabilité faisait l’objet d’une exploitation active dans la nature.
Réduire les risques liés aux vulnérabilités d’Ingress
La mise à niveau reste la principale mesure corrective, mais des contrôles supplémentaires peuvent contribuer à réduire les risques pendant le déploiement des correctifs et à renforcer la sécurité globale du cluster.
Les mesures ci-dessous visent à réduire l’exposition, à renforcer les autorisations et à améliorer la visibilité sur l’activité d’Ingress.
- Mettez à jour ingress-nginx vers la version 1.13.7, 1.14.3 ou une version ultérieure pour corriger complètement la vulnérabilité.
- Déployez un contrôleur d’admission validant pour bloquer les ressources Ingress utilisant le type de chemin ImplementationSpecific si une mise à niveau immédiate n’est pas possible.
- Limitez les autorisations de création ou de modification des ressources Ingress et réduisez l’accès RBAC d’ingress-nginx aux seuls espaces de noms et Secrets requis.
- SurveillezKubernetes les journaux d’audit et les modifications de configuration d’ingress-nginx afin de détecter les valeurs de chemin suspectes ou malformées et les mises à jour inattendues.
- Limitez l’ampleur des dégâts en appliquant des politiques réseau et en isolant les espaces de noms des déploiements ingress-nginx.
- Utilisez une surveillance de sécurité à l’exécution pour détecter un comportement anormal au sein des pods du contrôleur ingress-nginx, comme l’exécution inattendue de processus ou l’accès à des fichiers.
- Préparez la mise en quarantaine et la reprise en conservant les données d’audit Kubernetes et en testant régulièrement les plans de réponse aux incidents qui incluent des scénarios de compromission d’Ingress et du contrôleur.
Ces mesures contribuent à limiter l’ampleur des dégâts causés par une compromission d’Ingress et à renforcer la résilience de Kubernetes.
L’importance de la sécurité d’Ingress
Cette vulnérabilité met en évidence les enjeux de sécurité associés aux composants Kubernetes hautement privilégiés situés à la périphérie du cluster.
Si les mises à niveau rapides sont importantes, les associer à des contrôles d’accès plus stricts, à une meilleure surveillance et à des processus de réponse testés peut contribuer à limiter l’impact.
Intégrer la sécurité d’Ingress à une stratégie de résilience plus large favorise une protection plus homogène dans le temps.
L’accent mis sur la limitation des privilèges et la validation des accès reflète les principes fondamentaux du zero-trust.