Ungepatchte RCE-Lücke in Argo CD: Angreifer können Kubernetes-Cluster übernehmen (2026)

Die Sicherheitsfirma Synacktiv hat eine ungepatchte Schwachstelle im repo-server von Argo CD offengelegt, die es einem nicht authentifizierten Angreifer erlaubt, Befehle auszuführen und von dort aus einen kompletten Kubernetes-Cluster zu übernehmen. Es gibt weder ein Release mit Fix noch eine CVE. Wenn auch nur ein einziger Pod in Ihrem Cluster den internen Port des repo-server erreichen kann, sollten Sie ihn wie einen authentifizierten Angreifer behandeln, bis Sie eine Netzwerkisolierung eingerichtet haben. Dies ist einer der seltenen Fälle, in denen der Fix kein Versions-Update ist – sondern eine Firewall-Regel, die Sie selbst schreiben müssen.

Argo CD ist eines der am weitesten verbreiteten GitOps-Tools der Welt: Es überwacht Ihre Git-Repositories, erstellt Kubernetes-Manifeste und synchronisiert sie mit Ihren Clustern. Diese Aufgabe rückt es in das Zentrum Ihrer Deployment-Pipeline – und genau deshalb ist eine Schwachstelle zur Code-Ausführung an dieser Stelle so gefährlich.

Was ist die Schwachstelle im repo-server von Argo CD?

Die Schwachstelle steckt im repo-server, jener Argo-CD-Komponente, die Git-Repos klont und die Manifeste rendert, die festlegen, was Ihr Cluster deployt. Der repo-server stellt einen internen gRPC-Dienst bereit, und laut Synacktivs Analyse besitzt ein Endpunkt – /repository.RepoServerService/GenerateManifest – überhaupt keine Authentifizierung. Jeder, der den Port erreichen kann, kann eine präparierte Anfrage senden, die in der Ausführung von Befehlen endet.

Der Trick liegt in Kustomize. Wenn der repo-server ein Manifest rendert, kann er Kustomize aufrufen, das eine Option --helm-command akzeptiert, die die für Helm-Charts auszuführende Binärdatei benennt. Indem ein Angreifer das Feld BuildOptions in den KustomizeOptions der Anfrage kontrolliert, richtet er --helm-command auf sein eigenes Skript statt auf die echte helm-Binärdatei aus. Synacktiv demonstrierte dies gegen Argo CD v2.13.3: Ein nicht authentifizierter gRPC-Aufruf holte ein vom Angreifer kontrolliertes Git-Repo und führte das eingeschleuste Skript mit den Rechten des repo-server aus. Wie The Hacker News berichtete, beantwortet der Endpunkt nicht authentifizierte Anfragen direkt – es gibt keinen Login-Schritt zu umgehen, weil es schlicht keinen Login-Schritt gibt.

Wie aus dem Angriff eine vollständige Cluster-Übernahme wird

Code-Ausführung auf dem repo-server ist für sich genommen schon schlimm, doch was diese Lücke kritisch macht, ist die Eskalation zur Cluster-Kontrolle. Der repo-server hält das REDIS_PASSWORD in seiner Umgebung, und Argo CD nutzt Redis, um die Manifeste zwischenzuspeichern, die es gleich deployen will. Die Kette läuft so ab:

1. Senden eines nicht authentifizierten GenerateManifest-gRPC-Aufrufs mit bösartigen KustomizeOptions, um Befehlsausführung auf dem repo-server zu erlangen.
2. Auslesen des REDIS_PASSWORD aus der Umgebung und Verbinden mit dem Redis-Cache von Argo CD.
3. Vergiften des zwischengespeicherten Manifest-Schlüssels (mfst) mit einem bösartigen Kubernetes-Manifest und anschließendes Umschreiben des git-refs-Eintrags, sodass er auf einen älteren Commit-SHA zeigt.
4. Wenn Auto Sync läuft, sieht Argo CD etwas, das es für einen neuen Commit hält, gleicht ab und deployt die Workload des Angreifers in den Zielcluster.

Spätestens in Schritt vier führt der Angreifer keinen Code mehr in einem einzelnen Pod aus – er deployt beliebige Workloads mit genau den Sync-Berechtigungen, die Argo CD erteilt wurden, was bei den meisten Installationen weitreichende Kontrolle über den Cluster bedeutet. Auto Sync, ein Feature, das Teams gerade wegen seiner Bequemlichkeit aktivieren, wird zum Auslieferungsmechanismus.

Warum es keinen Patch und keine CVE gibt

Das ist der unangenehme Teil. Synacktiv gibt an, die Schwachstelle im Januar 2025 an die Maintainer von Argo CD gemeldet zu haben, und rund achtzehn Monate später, zum Zeitpunkt der öffentlichen Offenlegung am 1. Juli 2026, hatte das Kernprojekt noch immer kein Release mit Fix. Auch für das Kernproblem wurde keine CVE zugewiesen. Der Standpunkt der Maintainer lautet, dass der interne Dienst des repo-server nie dafür gedacht war, exponiert zu werden, und per Network Policy isoliert werden sollte – aus dieser Sicht handelt es sich also um eine Härtungslücke und nicht um einen zu patchenden Code-Fehler.

Das Problem sind die Standardeinstellungen. Das offizielle Helm-Chart wird mit diesen Network Policies deaktiviert ausgeliefert, sodass eine unveränderte Helm-Installation die Ports von repo-server und Redis für jeden Pod im Namespace erreichbar lässt. Ein zugehöriges Helm-Chart-Advisory (GHSA-47m3-95c7-g2g8) behandelt die Packaging-Seite, doch wenn Sie Argo CD mit Helm deployt und die Network Policies nie angefasst haben, sind Sie mit ziemlicher Sicherheit gerade jetzt exponiert.

Warum GitOps-Infrastruktur „Tier Zero“ ist

Die tiefere Lehre – und der Grund, warum das so viel Aufmerksamkeit erhielt – liegt darin, was Argo CD eigentlich ist. Es hat Lesezugriff auf Ihre privaten Repositories, Schreib- und Sync-Zugriff auf Ihre Cluster und hält Deployment-Secrets. Kompromittiert man es, bricht man nicht nur in eine einzelne App ein – man besitzt die Pipeline, die jede App ausliefert.

Analystin Devashri Datta brachte es in CSO Online unverblümt auf den Punkt: „GitOps-Engines sind keine Hilfsdienste; sie sind Tier-0-Control-Plane-Komponenten“, und „jeder Pod, der sie erreichen kann, wird zum Äquivalent eines authentifizierten Angreifers“. Sakshi Grover von IDC formulierte die Verteidigungsfrage als eine der Angriffspfade statt des Perimeters: Man müsse herausfinden, „welche Workloads mit der Control Plane von Argo CD kommunizieren können“ und ob „unnötige Vertrauensbeziehungen bestehen“ zwischen gewöhnlichen App-Pods und Ihrer GitOps-Engine. Die Erkenntnis ist, dass die Exposition ins Internet hier nie das richtige Bedrohungsmodell war – es ist die laterale Bewegung ausgehend von einem einzigen kompromittierten Pod.

Genau diese Denkweise – internem Datenverkehr nie standardmäßig vertrauen, alles segmentieren – steht auch hinter dem Wandel, über den wir in Zero Trust vs. VPN 2026 berichtet haben. Network Policies sind Mikrosegmentierung, angewendet innerhalb des Clusters.

So schützen Sie Ihren Cluster jetzt sofort

Da kein Patch zu installieren ist, besteht die Verteidigung in der Netzwerkisolierung. Argo CD liefert die Policy-Dateien mit; Helm-Nutzer müssen sie lediglich aktivieren.

1. Prüfen Sie, ob Sie exponiert sind. Listen Sie die Network Policies in Ihrem Argo-CD-Namespace auf:

kubectl get networkpolicy -n argocd

Wenn dabei nichts zurückkommt (oder keine Policy, die argocd-repo-server abdeckt), kann jeder Pod, der zum Namespace routen kann, den nicht authentifizierten gRPC-Port erreichen. Das ist der exponierte Zustand.

2. Wenden Sie die Network Policy für den repo-server an. Argo CD stellt argocd-repo-server-network-policy.yaml bereit, die den Ingress auf Port 8081 auf die legitimen internen Aufrufer beschränkt – den API-Server, den Application Controller, den ApplicationSet Controller und den Notifications Controller. Wenden Sie den vollständigen Satz der Argo-CD-Network-Policies (repo-server, Redis und die übrigen) aus der zu Ihrer Installation passenden Version an, oder aktivieren Sie sie in Ihren Helm-Values, falls Sie so deployen.

3. Verifizieren Sie. Bestätigen Sie, dass nun für jede Komponente Policies existieren, repo-server und Redis eingeschlossen:

kubectl get networkpolicy -A | grep argocd

4. Verkleinern Sie den Blast Radius. Behandeln Sie den Namespace von Argo CD als Tier Zero: Beschränken Sie, welche Workloads ihn teilen, begrenzen Sie seine Cluster-Berechtigungen auf genau das, was er zum Synchronisieren braucht, und prüfen Sie die Erreichbarkeit von RepoServerService auf dieselbe Weise, wie Sie es bei einer Admin-API tun würden. Wenn Sie Auto Sync für sensible Anwendungen nicht zwingend benötigen, entfernt seine Deaktivierung den automatisierten Pfad von der Cache-Vergiftung bis zum Deployment.

Exposition auf einen Blick

Deployment	Network Policies	repo-server von jedem Pod erreichbar?	Maßnahme
Helm-Chart, Standardeinstellungen	Aus	Ja – exponiert	Policies jetzt aktivieren
Manifeste, keine Policies hinzugefügt	Aus	Ja – exponiert	Bereitgestellte Policies anwenden
Policies angewendet + verifiziert	An	Nein – auf Argo-Komponenten beschränkt	Beibehalten und prüfen
Auto Sync bei sensiblen Apps	n. z.	Ermöglicht Cache-Poison → Deployment	Deaktivierung erwägen

Dies ist eher Control-Plane-Hygiene als Incident Response, und es geht Hand in Hand mit den Grundlagen der Absicherung jeder Maschine, die Sie betreiben – dieselbe Disziplin wie in der sicheren ersten Stunde auf einem neuen VPS. Wenn Sie Ihren eigenen Stack selbst hosten, ist die Schritt-für-Schritt-Anleitung zum Self-Hosting ein guter Ort, um sich diese Gewohnheiten von Anfang an anzueignen.

Häufig gestellte Fragen

Was ist der repo-server von Argo CD? Es ist die Argo-CD-Komponente, die Ihre Git-Repositories klont und in Kubernetes-Manifeste rendert – die eigentlichen Dateien, die dem Cluster sagen, was zu deployen ist. Er läuft als interner Dienst und stellt auf Port 8081 eine gRPC-API bereit, die die anderen Argo-CD-Komponenten aufrufen.

Gibt es einen Patch oder eine CVE für diese Schwachstelle? Nein. Zum Zeitpunkt der Offenlegung am 1. Juli 2026 gibt es kein Release mit Fix für das Kernprodukt Argo CD und keine CVE für das Kernproblem. Die Maintainer behandeln den internen Dienst als etwas, das Sie mit Network Policies isolieren müssen; ein separates Helm-Chart-Advisory (GHSA-47m3-95c7-g2g8) deckt die Packaging-Standardeinstellungen ab.

Bin ich betroffen, wenn ich Argo CD mit Helm installiert habe? Wahrscheinlich, es sei denn, Sie haben Network Policies ausdrücklich aktiviert. Das offizielle Helm-Chart wird mit deaktivierten Policies ausgeliefert, was die Ports von repo-server und Redis für jeden Pod im Namespace erreichbar lässt. Führen Sie kubectl get networkpolicy -n argocd aus, um dies zu prüfen.

Braucht ein Angreifer Internetzugang zu meinem Cluster? Nein, und genau das ist der Punkt. Die Bedrohung ist intern: Jeder Pod, der den gRPC-Port des repo-server erreichen kann, kann die nicht authentifizierte Anfrage senden. Eine einzige kompromittierte oder bösartige Workload innerhalb des Clusters genügt, weshalb der Fix in Segmentierung besteht und nicht nur in einer Firewall am Rand.

Ist Argo CD nur für Kubernetes? Ja. Argo CD ist ein deklaratives GitOps-Continuous-Delivery-Tool, das speziell für Kubernetes entwickelt wurde; es gleicht den Live-Zustand des Clusters mit in Git gespeicherten Manifesten ab. Genau diese enge Kopplung ist der Grund, warum sich eine Kompromittierung des repo-server so unmittelbar in eine Kompromittierung des Clusters übersetzt.

Sources

• Synacktiv — Unauthenticated RCE in Argo CD with CodeQL: die primäre technische Offenlegung, Endpunkt, Missbrauch von Kustomize --helm-command, Redis-Cache-Poisoning-Kette und Network-Policy-Mitigation.
• The Hacker News — Unpatched Argo CD Repo-Server Flaw Could Let Attackers Take Over Kubernetes Clusters: Zusammenfassung der Schwachstelle, des nicht authentifizierten gRPC-Endpunkts und der Offenlegungs-Timeline.
• CSO Online — Argo CD flaw shows why GitOps infrastructure should be treated as tier zero: Experteneinschätzung zu GitOps als Tier-0-Control-Plane und zum Denken in Angriffspfaden.
• GitHub — argoproj/argo-cd: das Argo-CD-Projekt, Security-Advisories und die bereitgestellten Network-Policy-Manifeste.