Auf den Punkt: Eine unbehandelte Argo-CD-Lücke zeigt, dass GitOps-Plattformen interne Cluster-Zugriffe genauso sicher schützen müssen wie externe Exponierungen, weil jede kompromittierte Pod direkt Code ausführen und Deployments manipulieren kann.
Eine Sicherheitslücke im weit verbreiteten Kubernetes-Tool Argo CD zeigt, dass GitOps-Plattformen mit demselben Schutzniveau wie zentrale Kontrollebenen behandelt werden müssen. Die Lücke erlaubt Angreifern mit Zugriff auf das interne Cluster-Netzwerk, beliebige Code-Befehle auszuführen und Deployments zu manipulieren.
Die Sicherheitsfirma Synacktiv hat eine Lücke in der repo-server-Komponente von Argo CD dokumentiert. Diese Komponente bezieht Inhalte aus Git-Repositories und generiert die Kubernetes-Manifeste für Ressourcen-Deployments im Cluster. Das Problem liegt in einem nicht authentifizierten gRPC-Endpunkt (GenerateManifest), über den Angreifer Kustomize-Optionen in Manifest-Anfragen injizieren können, um über Kustomizes Helm-Build-Funktionen beliebige Befehle auszuführen.
Die Ausnutzung erfordert Netzwerkzugriff auf den gRPC-Port des repo-server und auf die Redis-Datenbank des Clusters. Argo CD sieht zwar Kubernetes-Netzwerk-Richtlinien vor, um das zu verhindern — diese sind in Helm-Chart-Deployments aber nicht aktiviert. Synacktiv konnte in Tests das Redis-Passwort aus der repo-server-Umgebung auslesen, auf die Redis-Datenbank zugreifen und Deployment-Daten manipulieren. Mit aktivierter Auto-Sync-Funktion wurden so manipulierte Manifeste automatisch deployed. Synacktiv berichtete das Problem im Januar 2025 an die Argo-CD-Maintainer, die Lücke ist bis heute nicht gepatcht und wurde am 1. Juli 2026 öffentlich gemacht.
Für CISOs reicht es nicht aus, nur zu überprüfen, ob Argo CD nach außen exponiert ist. Entscheidend ist, welche anderen Workloads innerhalb des Kubernetes-Clusters die internen Services erreichen können. Da der gRPC-Service des repo-server keine Authentifizierung erzwingt, kann jeder Pod, der ihn erreicht, wie ein authentifizierter Angreifer agieren. Das bedeutet: Jede kompromittierte Anwendungs-Pod, jede falsch konfigurierte Service-Mesh oder jede benachbarte Workload mit lokaler Code-Ausführung kann direkt den GenerateManifest-Endpunkt abfragen oder den Redis-Cache angreifen — ohne dass das System nach außen exponiert sein muss.
GitOps-Plattformen wie Argo CD sind keine Hilfsdienste, sondern Tier-Zero-Kontrollkomponenten. Sie haben Lesezugriff auf private Git-Repositories, Schreib-/Sync-Zugriff auf Ziel-Cluster und verwalten Deployment-Secrets. Dieser Zugriff macht Argo CD zu einem attraktiven Ziel für Angreifer und erfordert Segmentierung auf Netzwerk- und Vertrauensebene. CISOs sollten evaluieren, welche Workloads mit der Argo-CD-Kontrollebene kommunizieren können, ob East-West-Traffic angemessen segmentiert ist und ob unnötige Vertrauensbeziehungen zwischen Anwendungs-Workloads und GitOps-Infrastruktur bestehen. Synacktiv empfiehlt, strikte Kubernetes-Netzwerk-Richtlinien zu setzen, um nicht vertrauenswürdige Pods vom Zugriff auf repo-server und Redis-Services abzusperren, bis ein Fix verfügbar ist.
Quelle: www.csoonline.com · Erschienen 2. Juli 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.7.2.