Défaut critique sur Argo CD expose l'exécution de code sans authentification et pourrait compromettre le cluster

Argo CD, l'outil de déclaration le plus couramment utilisé pour déployer des applications dans Kubernetes, entraîne une défaillance critique sans patch dans son composant repos qui permet d'exécuter le code sans authentification à condition qu'un attaquant puisse atteindre le port interne du service. La société de sécurité Synacktiv a publié les détails après avoir signalé la vulnérabilité en janvier 2025 et en attendant un arrangement sans succès; selon ses preuves, l'opération peut conduire à la prise totale de grappes.

Le noyau technique du problème est simple mais dangereux: repo-server expose en interne un service gRPC sans authentification et son appel GenerateManifest permet de contrôler l'option --helm-command de kustomize, l'outil qu'Argo CD utilise pour convertir des dépôts Git en manifestes Kubernetes. Synacktiv a montré qu'une requête non authentifiée peut pointer cette option sur un script hébergé dans un dépôt contrôlé par l'attaquant; quand kustomize exécute ce qu'il pense être "aide", il exécute le script malveillant et l'attaquant obtient l'exécution de code dans le pod-server de reste.

Cette vulnérabilité ne serait pas si exploitable si le réseau de grappes était segmenté, mais le problème opérationnel aggrave le risque : Les CD Argo Le graphique Helm laisse les politiques réseau désactivées par défaut(networkPolicy.create = false), ce qui signifie que tout pod engagé à l'intérieur du cluster peut atteindre les ports de repo-server internes. Synacktiv a également enchaîné l'exécution à distance avec une autre faiblesse dans la gestion du cache : lire le mot de passe de Reds à partir de variables d'environnement connectées au CD Reds Argo et "poisonné" le cache des déploiements, ce qui a provoqué la prochaine synchronisation automatique pour déployer des charges de l'attaquant. Cette séquence ravive des problèmes antérieurs où le cache n'était pas signé et dépendait de secrets qui pouvaient être exfiltrés ou réutilisés.

Les implications sont claires: Argo CD concentre l'accès aux dépôts et aux secrets et ses surfaces internes ont à plusieurs reprises donné un accès plus large au nécessaire. En 2025 et 2026, d'autres erreurs ont été corrigées qui ont permis de lire des lettres d'identité ou des secrets avec des jetons à faible privilège, et la tendance a été la même : les défaillances internes des composants qui facilitent l'escalade pour compromettre les déploiements complets.

Tant qu'il n'y a pas de patch officiel (aucune version corrigée ou CVE publique associée au rapport Synacktiv), la seule défense pratique est de traiter le réseau de cluster comme hostile et d'appliquer l'isolement immédiat. Activer les politiques du réseau Kubernetes pour empêcher tout pod CD non-Argo d'atteindre les ports du serveur de repos et de Reis, et confirmer leur statut avec des commandes comme kubectl obtenir la politique du réseau -A. Si vous avez installé Argo CD avec Helm, activez les politiques du graphique (par exemple, networkPolicy.create = vrai) ou de mettre en oeuvre ses propres politiques de réseau restrictives qui n'autorisent le trafic qu'entre les composants officiels d'Argo CD.

En plus de l'isolement du réseau, il convient de prendre des mesures opérationnelles supplémentaires : faire pivoter les mots de passe et les secrets sensibles (y compris le mot de passe Reis exposé), désactiver la synchronisation automatique jusqu'à ce que l'intégrité du dépôt et du cache soit vérifiée, inspecter les pods et les images à la recherche de processus inhabituels et d'enregistrements de connexion sortants, et appliquer des contrôles d'affranchissement supplémentaires tels que les politiques d'admission (OPA / Gatekeeper ou Kyverno), la numérisation d'images par CI et la détection de temps de performance (par exemple Falco). Pour une inspection rapide de l'installation, vérifiez les services de CD Argo kubectl obtenir svc -n argocd et kubectl obtenir pops -n argocd -o yaml pour localiser les variables d'environnement sensibles.

Synacktiv a créé un outil appelé argo-cdown qui automatise l'ensemble de la chaîne d'attaque et, de manière responsable, a retardé sa publication pour donner aux administrateurs le temps de garer leurs réseaux avant qu'ils ne deviennent massivement exploitables; il est approprié de suivre son canal et celui du projet Argo CD pour recevoir des alertes et des patchs. Pour une référence technique et pour obtenir les politiques et valeurs du graphique que vous devez activer, consultez la documentation et les dépôts officiels d'Argo CD dans GitHub et le guide des politiques du réseau Kubernetes: https: / / github.com / argoproj / argo-cd, https: / / www.synacktiv.com / et https: / / kubernetes.io / docs / concepts / services-réseaux / politiques du réseau /.

Bref, jusqu'à ce qu'Argo CD publie un patch, les équipes doivent supposer que le réseau de clusters est le vecteur le plus dangereux, appliquer un isolement strict entre les applications et les plates-formes de contrôle, vérifier et faire tourner les secrets, et préparer la détection et la réponse pour la manipulation des signaux dans le cache de déploiement. Cet incident rappelle que les plates-formes de prestation et de réconciliation continues, de par leur nature même, concentrent les privilèges et exigent des contrôles de défense approfondis en réseau, en identité et en télémétrie.