18 Monate ohne Fix: Wie eine Argo-CD-Lücke den ganzen Kubernetes-Cluster öffnet
Seit 18 Monaten klafft im Argo-CD-Repo-Server eine Lücke ohne Patch und ohne CVE. So übernehmen Angreifer den Kubernetes-Cluster. So sichern Sie ihn jetzt ab.
6 Min. Lesezeit
Seit 18 Monaten steckt im Argo-CD-Repo-Server eine Lücke, für die es bis heute keinen Patch und nicht einmal eine CVE-Nummer gibt. Der interne gRPC-Dienst prüft keine Identität. Wer ihn im Cluster erreicht, kann Befehle ausführen, das Redis-Cache vergiften und beim nächsten Sync eigene Workloads ausrollen. Ein einziger kompromittierter Pod reicht.
Das Wichtigste in Kürze
- Kein Patch, kein CVE: Synacktiv meldete den Fehler im Januar 2025 an die Argo-CD-Maintainer und veröffentlichte am 1. Juli 2026 die Details. Ein Fix fehlt weiterhin.
- Der Repo-Server ist das Einfallstor: Sein gRPC-Dienst läuft ohne Authentifizierung. Über eine präparierte Kustomize-Option führt ein Angreifer unauthentifiziert Code aus.
- Die Abwehr liegt im Netz: Kubernetes-NetworkPolicies schotten Repo-Server und Redis ab. Argo CD liefert die Regeln mit, doch bei Helm-Installationen sind sie standardmäßig aus.
Verwandt:Kubernetes-Governance in Multi-Cloud-Umgebungen / Was das Cilium-Upgrade im Cluster kappen kann
Was Synacktiv im Repo-Server gefunden hat
Der Repo-Server ist die Komponente, die Argo CD die eigentliche Arbeit machen lässt. Er liest die Git-Repositories und baut daraus die fertigen Kubernetes-Manifeste. Damit die anderen Argo-Bausteine ihn ansprechen können, bietet er einen internen gRPC-Endpunkt an. Dieser Endpunkt fragt nach keiner Identität. Jeder Prozess, der ihn über das Netz erreicht, darf ihm Anfragen schicken.
Genau hier setzt der Angriff der Sicherheitsforscher von Synacktiv an. Argo CD ruft für den Manifest-Bau das Standard-Werkzeug Kustomize auf. Kustomize kennt eine Option, mit der sich der Pfad zum Helm-Binary setzen lässt. Über eine präparierte Anfrage zeigt diese Option auf ein beliebiges Kommando. Das Ergebnis ist unauthentifizierte Befehlsausführung mitten in der Deploy-Kette.
Der Weg endet nicht am Repo-Server. Die Forscher lasen das Redis-Passwort aus einer Umgebungsvariablen, verbanden sich mit dem Argo-CD-Cache und manipulierten die dort gespeicherten Deployment-Daten. Beim nächsten automatischen Abgleich rollte Argo CD brav den untergeschobenen Workload aus. Aus einem Lesezugriff auf einen Hilfsdienst wird so die Kontrolle über den gesamten Cluster.
Warum ein Deploy-Werkzeug zum Cluster-Schlüssel wird
GitOps hat die Argumente auf seiner Seite. Der gewünschte Zustand steht im Git, ein Controller gleicht ihn ununterbrochen mit dem laufenden Cluster ab. Nachvollziehbar, versioniert, ohne manuelle kubectl-Bastelei. Der Preis dieser Bequemlichkeit steht selten im Architektur-Diagramm: Wer den Deploy-Pfad kontrolliert, kontrolliert alles, was am Ende dieses Pfades läuft.
Argo CD entscheidet, welche Container in Produktion gehen. Es hält die Zugangsdaten, die es für den Abgleich braucht. Es hat per Definition Schreibrecht auf den Cluster. Ein Angreifer, der diese Maschinerie übernimmt, muss keine einzelne Anwendung mehr knacken. Er schreibt sich selbst in den erwünschten Zustand und lässt den Controller die Drecksarbeit erledigen.
Deshalb argumentieren Fachleute wie bei diesem Fall, GitOps-Infrastruktur gehöre als Tier-0 behandelt. Also auf derselben Schutzstufe wie das Identitätssystem oder die Zertifikatsstelle. Nicht als bloßes Deployment-Tool im zweiten Rang, sondern als das, was es ist: die Steuerzentrale der Produktion.
Fünf Schritte, die den Repo-Server jetzt absichern
Auf einen Hersteller-Patch zu warten ist keine Option, weil es keinen gibt. Die gute Nachricht: Der Angriff braucht Netzzugang zum Repo-Server. Genau dort lässt er sich stoppen.
- NetworkPolicies aktivieren. Argo CD liefert fertige Regeln mit, die nur die eigenen Komponenten an Repo-Server und Redis heranlassen. Bei Helm-Installationen sind sie ausgeschaltet. Einschalten ist der wirksamste Einzelschritt.
- Repo-Server und Redis segmentieren. Beide Ports gehören in ein eigenes Netzsegment. Kein anderer Pod im Cluster hat dort etwas zu suchen.
- Exposure prüfen. Kontrollieren, welche Workloads den gRPC-Port heute erreichen können. In Standard-Helm-Setups ist das oft der komplette Cluster.
- Chart-Defaults hinterfragen. Der Fall zeigt ein Muster: Sichere Optionen liegen bei, sind aber abgeschaltet. Das gilt über Argo CD hinaus für viele Helm-Charts.
- Sync-Verhalten beobachten. Unerwartete Deployments oder Änderungen am gewünschten Zustand sind das Warnsignal. Wer den Redis-Cache manipuliert, hinterlässt Spuren im Abgleich.
Standard-Installation gegen gehärtetes Setup
Der Unterschied zwischen angreifbar und abgesichert liegt nicht in einer neuen Komponente, sondern in Voreinstellungen, die man kennen und setzen muss.
| Aspekt | Standard-Helm-Install | Gehärtetes Setup |
|---|---|---|
| NetworkPolicies | ausgeschaltet | aktiv, nur Argo-Komponenten |
| Repo-Server-Erreichbarkeit | clusterweit | isoliertes Segment |
| Redis-Cache | aus dem Cluster erreichbar | abgeschottet |
| Wirkung eines Ein-Pod-Kompromisses | Weg zur Cluster-Übernahme | am Segment gestoppt |
Was Admins aus dem Fall mitnehmen
Die eigentliche Lehre steckt nicht in Argo CD, sondern in der Annahme dahinter. Interne Dienste galten lange als vertrauenswürdig, weil sie hinter der Cluster-Grenze liegen. Der gRPC-Endpunkt ohne Authentifizierung ist die logische Folge dieser Annahme. Sie hält nicht mehr, sobald ein einziger Pod im selben Netz übernommen wird.
Wer GitOps betreibt, sollte die Steuerzentrale so behandeln wie die Türen zum Serverraum. Segmentiert, überwacht, mit ausdrücklich gesetzten Regeln statt geerbter Defaults. Der Patch für diese Lücke fehlt noch. Die Kontrolle über das eigene Netz fehlt niemandem, der sie sich nimmt.
Häufige Fragen
Gibt es für die Argo-CD-Lücke einen Patch?
Nein. Synacktiv meldete den Fehler im Januar 2025, öffentlich wurde er am 1. Juli 2026. Bis heute liegt weder ein Fix noch eine CVE-Nummer vor. Die Absicherung erfolgt über Kubernetes-NetworkPolicies.
Bin ich betroffen, wenn ich Argo CD über Helm installiert habe?
Wahrscheinlich ja, solange die NetworkPolicies aus sind. Der Helm-Chart liefert die Schutzregeln mit, lässt sie aber standardmäßig deaktiviert. Ohne sie ist der Repo-Server oft aus dem gesamten Cluster erreichbar.
Wie läuft der Angriff konkret ab?
Über den unauthentifizierten gRPC-Dienst des Repo-Servers und eine präparierte Kustomize-Option, die auf ein beliebiges Kommando zeigt. Danach wird das Redis-Passwort ausgelesen, der Cache manipuliert und beim nächsten Sync ein fremder Workload ausgerollt.
Was ist der schnellste Schutzschritt?
Die mitgelieferten NetworkPolicies aktivieren, sodass nur Argo-CD-eigene Komponenten Repo-Server und Redis erreichen. Das unterbindet den Netzzugang, auf den der Angriff angewiesen ist.
Lesetipps der Redaktion
Quelle Titelbild: KI-generiert (Juli 2026)
