Chaos Mesh, l’outil open source de chaos engineering pour Kubernetes, fait l’objet d’une alerte majeure. Des chercheurs de JFrog ont découvert quatre failles critiques, baptisées Chaotic Deputy, exposant les clusters à des risques d’élévation de privilèges et d’exécution de code arbitraire. Concrètement, un attaquant qui compromet un simple pod peut exploiter ces vulnérabilités pour se déplacer dans le cluster et en prendre le contrôle.
Chaos Mesh : du chaos contrôlé… au chaos incontrôlable
Chaos Mesh est conçu pour introduire volontairement des pannes (arrêts de pods, latence réseau, erreurs systèmes) afin de tester la résilience des applications déployées sur Kubernetes. Par essence, il possède donc des privilèges élevés au sein du cluster.
Ironie du sort : l’outil censé tester la robustesse des clusters se transforme ici en bombe à retardement. Le chaos n’était pas censé être si littéral. Et c’est précisément ce que révèle la campagne Chaotic Deputy.
Quatre vulnérabilités critiques découvertes
Les chercheurs ont identifié quatre CVE. Trois sont classées critiques et une est jugée importante :
- CVE-2025-59358 (critique, CVSS 9.8) : serveur GraphQL non authentifié exposé par le Chaos Controller Manager — permet l’arrêt de processus arbitraires sur n’importe quel pod (risque de déni de service global).
- CVE-2025-59359 (critique, CVSS 9.8) : mutation GraphQL cleanTcs vulnérable à une injection de commandes système — exécution de commandes arbitraires dans des conteneurs.
- CVE-2025-59360 (critique, CVSS 9.8) : mutation GraphQL killProcesses vulnérable à une injection système — arrêt ou exécution de processus arbitraires dans des pods ciblés.
- CVE-2025-59361 (important, CVSS 7.5) : mutation GraphQL cleanIptables vulnérable à une injection système — possibilité de manipuler iptables et d’exécuter des commandes sur les pods/nœuds.
Ces vulnérabilités sont détaillées en profondeur dans le rapport officiel de JFrog Security Research, qui a baptisé cette campagne Chaotic Deputy. Les chercheurs expliquent comment ces failles, exploitables avec un simple accès réseau au cluster, permettent un mouvement latéral et une prise de contrôle totale de Kubernetes.
Kubernetes face au chaos : pourquoi ces failles sont explosives ?
Ces vulnérabilités affectent toutes les versions de Chaos Mesh antérieures à 2.7.3.
Elles sont particulièrement dangereuses car elles peuvent être exploitées avec des prérequis minimaux : il suffit d’un accès réseau au cluster, par exemple via un pod compromis.
L’impact est majeur :
- Déni de service sur le cluster en arrêtant des processus critiques.
- Exécution de code arbitraire dans les conteneurs.
- Escalade de privilèges jusqu’au contrôle complet du cluster.
En clair : si votre cluster tourne avec une version vulnérable de Chaos Mesh, un attaquant n’a pas besoin de génie. Il lui suffit de s’installer confortablement dans un pod compromis, et il peut bientôt se balader comme chez lui dans tout votre cluster.
Même certains services cloud sont concernés : Azure Chaos Studio, qui repose sur Chaos Mesh, a dû appliquer en urgence les correctifs de sécurité.
Vous voulez aller plus loin et apprendre à sécuriser vos clusters Kubernetes contre ce type de vulnérabilité ? Découvrez notre formation Kubernetes Avancé avec ateliers pratiques et cas concrets.
L’équipe Ambient IT
Rustines temporaires ou vrai correctif : à vous de choisir
Les mainteneurs de Chaos Mesh ont publié le correctif avec la version 2.7.3 le 21 août 2025. La mise à jour est indispensable et doit être appliquée sans délai.
Le seul vrai bouclier, c’est la mise à jour vers 2.7.3. Tout le reste, NetworkPolicies, blocage de ports, isolement, ce sont des rustines temporaires. Ça aide, mais ça ne sauvera pas votre cluster si vous repoussez le patch.
En attendant un patch, certaines mesures peuvent réduire le risque :
- Restreindre l’accès réseau au Chaos Controller Manager et au Chaos Daemon via des Network Policies.
- Désactiver ou filtrer l’accès au serveur de debug ChaosCTL (port 10082).
- Éviter le déploiement de Chaos Mesh sur des environnements sensibles ou partagés tant que la mise à jour n’est pas appliquée.
Ces bonnes pratiques permettent de limiter la surface d’attaque, mais elles ne remplacent pas le correctif officiel.
Que faut-il retenir ?
L’épisode Chaotic Deputy illustre un paradoxe bien connu : les outils conçus pour tester la robustesse des systèmes peuvent devenir des vecteurs de vulnérabilités critiques s’ils ne sont pas surveillés et maintenus correctement.
Pour les ingénieurs Kubernetes, la leçon est double :
- Toujours maintenir à jour les outils tiers déployés dans le cluster, même ceux utilisés uniquement pour du test ou du chaos engineering.
- Durcir la sécurité en appliquant le principe du moindre privilège, même pour des composants qui, par design, requièrent une forte intégration avec le cluster.
En d’autres termes : le chaos doit rester une expérience contrôlée, pas une brèche ouverte aux attaquants.
Conclusion : patcher avant qu’il ne soit trop tard !
Les failles Chaotic Deputy rappellent crûment que la sécurité doit rester une priorité absolue, y compris lorsqu’il s’agit d’outils censés renforcer la résilience. Chaos Mesh reste un atout puissant pour le chaos engineering, mais entre de mauvaises mains ou avec une version vulnérable, il se transforme en véritable porte d’entrée pour les attaquants.
La recommandation est simple : mettez à jour immédiatement vers Chaos Mesh 2.7.3. Les mesures temporaires (NetworkPolicies, blocage du ChaosCTL, isolement) peuvent réduire la surface d’attaque, mais elles ne remplaceront jamais le correctif officiel. Plus vous attendez, plus vous laissez à un attaquant la possibilité de transformer votre cluster en terrain de jeu.
En clair : gardez le chaos en labo, pas en production. Le chaos engineering doit rester une expérience contrôlée, pas un test grandeur nature imposé par des cybercriminels. Patch rapide, surveillance continue et limitation des privilèges sont vos meilleurs alliés pour continuer à bénéficier de Chaos Mesh… sans en subir les dérives.
