Ungepatchte Argo-CD-Lücke im Repo-Server bedroht Kubernetes-Cluster

Synacktiv demonstrierte den Angriff an Argo CD v2.13.3. Eine gepatchte Version gibt es laut dem Unternehmen nicht; eine vollständige Liste betroffener Versionen wurde nicht veröffentlicht. Die Schwachstelle sitzt im Dienst GenerateManifest des repo-server und hängt mit kustomize zusammen, einem Standardwerkzeug, das Argo CD zur Umwandlung von Repository-Dateien in Kubernetes-Manifeste nutzt.

Konkret machte sich Synacktiv die Option –helm-command zunutze, mit der kustomize festlegt, welches helm-Binary aufgerufen werden soll. Eine nicht authentifizierte Anfrage an den GenerateManifest-Dienst kann diese Option demnach auf ein Skript umbiegen, das aus einem von Angreifern kontrollierten Git-Repository geladen wird. Wenn kustomize anschließend läuft, wird statt helm dieses Skript ausgeführt.

Der Umstand, dass es sich um einen „internen“ Dienst handelt, schützt dabei nicht automatisch. Argo CD liefert zwar Kubernetes-Netzwerkrichtlinien mit, die den repo-server von allen Komponenten außer den eigenen abschotten sollen. Synacktiv stellte jedoch fest, dass das Helm-Chart — ein verbreiteter Installationsweg für Argo CD — diese Richtlinien standardmäßig deaktiviert lässt: networkPolicy.create steht dort auf false.

In dieser Konfiguration reicht laut Synacktiv bereits die Kompromittierung eines einzelnen Pods im Cluster, um den repo-server zu erreichen und die Lücke auszunutzen. Die Ausführung von Code auf dem repo-server ist dabei nur der erste Schritt. Synacktiv nutzte den Zugriff nach eigenen Angaben, um das Redis-Passwort des Clusters aus einer Umgebungsvariable auszulesen, sich mit dem Redis-Cache von Argo CD zu verbinden und die gespeicherten Deployment-Daten zu manipulieren. Bei der nächsten automatischen Synchronisierung rollte Argo CD dann eine von den Angreifern bereitgestellte Workload aus.

Damit lebt laut Synacktiv im Kern CVE-2024-31989 wieder auf. Diese 2024 von Cycode entdeckte Schwachstelle bestand darin, dass Argo CDs Redis ohne Passwort betrieben wurde, sodass jeder Pod im Cluster den Deployment-Cache manipulieren konnte. Argo CD behob das Problem durch ein Redis-Passwort. Da der Cache selbst aber weiterhin nicht signiert ist, öffnet das erneute Auslesen des Passworts denselben Angriffsweg wieder.

Eine gepatchte Version existiert derzeit nicht. Als Gegenmaßnahme bleibt nach Darstellung von Synacktiv deshalb vor allem die Netzwerkisolation. Aktiviert werden sollten Kubernetes-Netzwerkrichtlinien, sodass nur die eigenen Argo-CD-Komponenten die Ports von repo-server und Redis erreichen können. Die Richtliniendateien stellt Argo CD bereit; Nutzer des Helm-Charts müssen sie allerdings ausdrücklich einschalten.

Prüfen lässt sich der aktive Zustand mit „kubectl get networkpolicy -A“. Eine sauber abgesicherte Installation zeigt laut Synacktiv für jede Komponente eine eigene Netzwerkrichtlinie, einschließlich repo-server und Redis. Fehlen diese Richtlinien, sind deren Ports vom restlichen Cluster aus erreichbar.

Synacktiv hat zudem mit argo-cdown ein Werkzeug entwickelt, das den kompletten Angriff automatisiert. Das Unternehmen hält das Tool vorerst zurück, um Verteidigern Zeit zum Absichern ihrer Netzwerkrichtlinien zu geben, und will es später auf GitHub veröffentlichen, damit Administratoren ihre eigenen Deployments testen können.

Es ist nicht das erste Mal, dass interne Funktionen von Argo CD zum Problem werden. Im September 2025 schloss das Projekt CVE-2025-55190; dabei konnte ein API-Token mit einfachem Lesezugriff an die Git-Repository-Zugangsdaten eines Projekts gelangen, worauf The Hacker News damals hinwies. Im Mai 2026 ermöglichte CVE-2026-42880 dann Benutzern mit reinem Lesezugriff, Kubernetes-Secrets im Klartext auszulesen.