La vulnérabilité non corrigée pourrait donner aux attaquants une voie depuis un pod compromis vers un contrôle plus large sur les déploiements Kubernetes.
Une vulnérabilité récemment révélée dans Argo CD attire l’attention sur les risques de sécurité des plates-formes GitOps, les chercheurs avertissant que la faille pourrait permettre aux attaquants qui s’implantent dans un cluster Kubernetes d’exécuter du code et de manipuler les déploiements d’applications.
La société de sécurité Synacktiv a déclaré dans un rapport que la faille affecte le composant de serveur de dépôt d’Argo CD, qui récupère le contenu des référentiels Git et génère des manifestes Kubernetes utilisés pour déployer des ressources dans un cluster. Argo CD est l’un des outils Kubernetes les plus populaires et est basé sur le paradigme GitOps.
« Argo CD nécessite des privilèges importants au sein du cluster », a déclaré Synacktiv. « De plus, il a accès à des référentiels Git privés, ce qui en fait une cible attrayante pour les attaquants. »
Le problème se concentre sur le point de terminaison gRPC GenerateManifest non authentifié du serveur de dépôt. Synacktiv a déclaré qu’un attaquant capable d’atteindre ce point de terminaison pourrait fournir des options Kustomize dans une demande de génération de manifeste et abuser des options de construction liées à Helm de Kustomize pour exécuter des commandes contrôlées par l’attaquant.
L’exploitation nécessite l’accès à la fois au port gRPC du serveur de dépôt et au port de la base de données Redis, qui ne doivent pas être exposés aux utilisateurs. Argo CD fournit des politiques réseau Kubernetes conçues pour empêcher ce scénario, mais ces protections ne sont pas activées par défaut dans les déploiements de chartes Helm, selon Synacktiv.
Dans de tels déploiements, la compromission d’un seul pod à l’intérieur du cluster pourrait suffire à donner à un attaquant l’accès interne nécessaire pour exploiter la vulnérabilité.
Synacktiv a déclaré avoir pu utiliser la faille pour obtenir le mot de passe Redis de l’environnement du serveur de dépôt et accéder à la base de données Redis d’Argo CD. Les chercheurs ont ensuite manipulé les données de déploiement mises en cache, permettant ainsi le déploiement automatique d’un manifeste malveillant lorsque la fonction de synchronisation automatique d’Argo CD était activée.
Si la synchronisation automatique n’est pas activée, l’exploitation nécessiterait qu’un utilisateur synchronise manuellement l’application.
Synacktiv a divulgué publiquement les détails le 1er juillet 2026, après avoir signalé pour la première fois le problème aux responsables d’Argo CD en janvier 2025. La vulnérabilité n’est toujours pas corrigée et la société a recommandé des politiques réseau Kubernetes strictes pour empêcher les pods non fiables d’atteindre le serveur de dépôt et les services Redis jusqu’à ce qu’un correctif soit disponible.
Évaluation de l’exposition interne du cluster
Pour les RSSI, la question clé n’est pas seulement de savoir si Argo CD est exposé à Internet, mais aussi de savoir si d’autres charges de travail au sein du cluster Kubernetes peuvent atteindre ses services internes.
« Comme le service gRPC du serveur de dépôt n’impose pas l’authentification, tout pod qui peut l’atteindre devient équivalent à un attaquant authentifié », a déclaré Devashri Datta, chercheur en cybersécurité. « Dans un cluster typique, cela signifie que tout module d’application compromis, maillage de services mal configuré ou charge de travail adjacente avec exécution de code local peut directement interroger le point de terminaison GenerateManifest ou accéder au cache Redis, aucune exposition Internet n’est requise. »
Les organisations ne devraient pas assimiler « ne pas être connecté à Internet » à « faible risque », car les attaques modernes commencent souvent par la compromission d’une charge de travail interne, selon Sakshi Grover, responsable de recherche senior pour la recherche sur les services de cybersécurité chez IDC Asie/Pacifique.
« Les RSSI devraient donc évaluer quelles charges de travail peuvent communiquer avec le plan de contrôle Argo CD, si le trafic est-ouest est correctement segmenté et s’il existe des relations de confiance inutiles entre les charges de travail des applications et l’infrastructure GitOps », a déclaré Grover. « L’évaluation devrait se concentrer sur les voies d’attaque plutôt que sur l’exposition du périmètre. »
Traiter GitOps comme un niveau zéro
La faille souligne également le rôle que jouent les plateformes GitOps dans le contrôle du déploiement de logiciels sur l’infrastructure de l’entreprise.
« Les moteurs GitOps ne sont pas des services utilitaires ; ce sont des composants de plan de contrôle de niveau 0 », a déclaré Datta. « De par sa conception, Argo CD détient un accès en lecture aux référentiels privés, un accès en synchronisation/écriture aux clusters cibles et la garde des secrets de déploiement. Il se situe à l’intersection précise du code source, de la gestion de la configuration et de l’infrastructure en direct. »
Ce niveau d’accès signifie qu’une compromission d’Argo CD peut s’étendre au-delà d’une seule application. Un attaquant pourrait transformer la plate-forme utilisée pour déployer des applications en un canal pour les manifestes malveillants, tout en interférant avec le comportement de synchronisation automatique et en extrayant les informations d’identification mises en cache dans les systèmes de support tels que Redis.
Une compromission de ces plateformes pourrait influencer la livraison de logiciels à grande échelle, en faisant des actifs stratégiques qui devraient être soumis à une gouvernance plus stricte et à des contrôles d’accès privilégiés similaires à ceux appliqués aux plateformes d’identité et autres systèmes de gestion critiques.
