Des chercheurs en cybersécurité ont révélé plusieurs failles critiques dans Chaos Mesh vulnérabilités, Kubernetes sécurité, RCE, cluster takeover, qui, si elles sont exploitées, peuvent conduire à une prise de contrôle totale de clusters Kubernetes.
Détails techniques et CVE (mai–août 2025) pour Chaos Mesh vulnérabilités, Kubernetes sécurité, RCE, cluster takeover
Chaos Mesh est une plateforme open source de chaos engineering conçue pour injecter des défaillances et simuler des anomalies dans des environnements cloud‑natifs. Selon le rapport transmis par JFrog à The Hacker News, plusieurs composants de Chaos Mesh, et en particulier le Chaos Controller Manager, présentent des défauts de sécurité graves qui exposent le cluster Kubernetes.
« Attackers need only minimal in‑cluster network access to exploit these vulnerabilities, execute the platform’s fault injections (such as shutting down pods or disrupting network communications), and perform further malicious actions, including stealing privileged service account tokens, » JFrog said in a report shared with The Hacker News.
Les vulnérabilités, regroupées sous l’appellation « Chaotic Deputy », sont décrites ci‑dessous avec leurs scores CVSS :
- CVSS 7,5 — le Chaos Controller Manager expose un serveur de débogage GraphQL sans authentification à l’ensemble du cluster Kubernetes ; ce serveur fournit une API capable de tuer des processus arbitraires dans n’importe quel pod, entraînant un déni de service à l’échelle du cluster (CVE‑2025‑59358).
- CVSS 9,8 — la mutation cleanTcs dans le Chaos Controller Manager est vulnérable à une injection de commandes du système d’exploitation (CVE‑2025‑59359).
- CVSS 9,8 — la mutation killProcesses dans le Chaos Controller Manager est vulnérable à une injection de commandes du système d’exploitation (CVE‑2025‑59360).
- CVSS 9,8 — la mutation cleanIptables dans le Chaos Controller Manager est vulnérable à une injection de commandes du système d’exploitation (CVE‑2025‑59361).
JFrog précise que la vulnérabilité du serveur GraphQL résulte d’un mécanisme d’authentification insuffisant dans le Chaos Controller Manager, ce qui permet à des attaquants non authentifiés d’exécuter des commandes arbitraires sur le Chaos Daemon et d’obtenir un contrôle étendu sur le cluster.
Un acteur malveillant disposant d’un accès réseau depuis l’intérieur du cluster — par exemple via une application compromise ou un pod mal configuré — pourrait chaîner les vulnérabilités (CVE‑2025‑59359, CVE‑2025‑59360, CVE‑2025‑59361 et/ou CVE‑2025‑59358) pour obtenir une exécution de code à distance (RCE) sur l’ensemble du cluster, y compris dans une configuration par défaut de Chaos Mesh.
Avec cet accès, les attaquants peuvent potentiellement exfiltrer des données sensibles, perturber des services critiques, ou se déplacer latéralement dans le cluster pour tenter d’escalader des privilèges.
Correctifs publiés le 21 août 2025 et recommandations d’atténuation
Après une divulgation responsable effectuée le 6 mai 2025, les défauts identifiés ont été corrigés par les mainteneurs de Chaos Mesh dans la version 2.7.3 publiée le 21 août 2025. Les équipes exploitant Chaos Mesh sont invitées à appliquer la mise à jour dès que possible.
Lorsque le déploiement immédiat du correctif n’est pas possible, JFrog recommande plusieurs mesures d’atténuation :
- Restreindre le trafic réseau vers le daemon de Chaos Mesh et vers l’API server afin de limiter l’accès depuis des pods ou des réseaux non approuvés.
- Éviter d’exécuter Chaos Mesh dans des environnements ouverts ou faiblement sécurisés, et limiter les privilèges des comptes de service utilisés par la plateforme.
- Surveiller les logs et comportements anormaux liés aux injections de défaillances et aux appels GraphQL non authentifiés.
Les opérateurs doivent également auditer les configurations réseau et les règles RBAC pour s’assurer qu’aucun composant ne dispose de droits excessifs permettant d’exploiter ces failles.
Prochaines étapes pour les équipes
- Planifier et appliquer la mise à jour vers Chaos Mesh 2.7.3 sur tous les environnements concernés.
- Si mise à jour impossible immédiatement, mettre en place des règles réseau strictes et revoir les autorisations des comptes de service.
- Procéder à des contrôles d’intégrité et à des analyses post‑incident en cas de signes d’exploitation (processus tués, modifications anormales d’iptables, exfiltration).
Les failles identifiées illustrent l’importance de restreindre les surfaces d’attaque internes et de protéger les interfaces d’administration, notamment les serveurs de débogage exposés sans authentification. Les équipes de sécurité doivent traiter ces correctifs comme prioritaires pour réduire le risque d’un cluster takeover.