Argo CD Sicherheitslage 2026: Vier kritische Lücken, drei ohne CVE – der Repo-Server als Angriffsziel

Argo CD ist der De-facto-Standard für GitOps auf Kubernetes: In der Argo-Community-Umfrage 2023 gaben 93 Prozent der Befragten an, das Tool in Produktion einzusetzen. Genau dort, im Zentrum der Deployment-Pipeline, hat sich die Sicherheitslage im Oktober 2026 zugespitzt. Am 7. Oktober veröffentlichte das Projekt sechs Sicherheitsadvisories in einem Rutsch — vier davon mit der Höchstbewertung CVSS 9.9 (kritisch). Drei der vier kritischen Lücken haben bis heute keine CVE-Nummer. Für Teams, deren Patch-Prozesse an CVE-Feeds und Scanner hängen, ist das eine strukturelle Blindstelle. Dazu kommt eine seit Juli 2026 bekannte, weiterhin ungepatchte Schwachstelle im Repo-Server, die unauthentifizierten Angreifern Codeausführung ermöglicht. Zeit für einen nüchternen Blick auf die Angriffsfläche des wichtigsten GitOps-Controllers.

Sechs Advisories, vier kritische — und kaum CVE-Sichtbarkeit

Alle sechs am 7. Oktober 2026 veröffentlichten Advisories sind in denselben vier Releases behoben: v3.3.15, v3.4.10, v3.5.4 und v3.6.0-rc2. Vier davon tragen die Bewertung CVSS 9.9. Doch nur eine Lücke hat es bislang in die NVD geschafft: CVE-2026-55797, von GitHub mit 8.8 bewertet. Eine zweite, CVE-2026-77459, besitzt eine CVE-ID, aber noch keinen NVD-Eintrag. Drei der vier CVSS-9.9-Findings haben gar keine CVE-Nummer, und fünf der sechs GHSA-Records liefern in OSV einen 404. Wer seine Upgrade-Priorisierung ausschließlich aus CVE-Feeds speist, sieht von dieser Welle nur einen Bruchteil.

Der Repo-Server: Nadelöhr der GitOps-Pipeline

Vier der sechs Bugs konvergieren auf einer Komponente: dem argocd-repo-server, dem Pod, der Git-Inhalte in Kubernetes-Manifeste übersetzt. Er hält die Git-, Helm- und OCI-Zugangsdaten aller Repositories der Installation. Drei unterschiedliche Angriffspfade beginnen mit Inhalten in einem Repository: ein Jsonnet-Datei-Lesepfad (verfolgbar bis v0.9.0, 2018), ein Kustomize-Remote-Ref über git fetch --upload-pack (seit v2.7.0) und eine Helm-Plugin-Ausführung über configHome mit --enable-helm.

Keine dieser Lücken erfordert mehr als die Fähigkeit, Inhalte in ein Repository zu committen, aus dem eine Application synchronisiert — im GitOps-Modell eine Routineberechtigung für App-Teams, CI-Jobs und zunehmend automatisierte Agenten. Der Confused-Deputy-Effekt ist das eigentliche Problem: Ein Entwickler, der nur seinen eigenen Namespace ändern darf, landet in einem Prozess, der die Zugangsdaten aller Mandanten hält — genau das S:C (Scope Change) steht in allen vier CVSS-Vektoren.

CVE-2026-55797: Command Injection über SSH-Proxy

Die einzige Lücke mit NVD-Eintrag ist eine Command Injection (GHSA-j6cw-g6p4-7hch, CWE-78): Bei SSH-Git-Repositories mit Proxy-URL werden Proxy-Host und -Port ungeprüft in einen SSH-ProxyCommand kopiert. Ein Hostname mit Shell-Metazeichen bricht aus dem Kommando aus und führt beliebigen Code im Repo-Server aus. Betroffen sind alle Versionen ab v2.11.0; eingeführt wurde das Verhalten im Januar 2024 mit der SOCKS5-Proxy-Unterstützung. Auslösen kann die Lücke, wer ein Repository oder eine Credential-Template anlegen darf — inklusive projektweiter Repository-Berechtigungen oder argocd repo add --proxy. Der Fix validiert Proxy-URLs über eine Allowlist: SSH-Proxies nur noch socks5/socks5h, nicht-leerer Host, Port 1–65535, Hostnamen ausschließlich alphanumerisch mit Punkten und Bindestrichen.

Der AppProject-Bypass: Multi-Tenant-GitOps wackelt

Für Multi-Tenant-Betriebe ist CVE-2026-77459 (GHSA-fmxq-cgp8-87wp, CVSS 9.9, CWE-863) die interessanteste Lücke: Argo CD prüft vor dem Anlegen von Ressourcen normalerweise, ob eine Application ihrem AppProject entspricht — aber die Hooks PreDelete und PostDelete überspringen diese Prüfung komplett und werden mit den Credentials des Application-Controllers auf dem Ziel-Cluster ausgeführt. „In einer typischen Installation ist dieser Zugriff breit, sodass ein Mandant ein clusterweites Objekt wie eine ClusterRoleBinding anlegen kann", heißt es im Advisory. Der PostDelete-Pfad habe die Projektprüfung seit v2.10.0 „nie angewendet".

Ungepatcht seit Juli: die „Octopus Trap"

Seit dem 1. Juli 2026 ist eine weitere Repo-Server-Schwachstelle öffentlich, für die es weiterhin weder Fix noch CVE gibt. Synacktiv demonstrierte eine unauthentifizierte Remote-Code-Execution: Der interne gRPC-Dienst des Repo-Servers prüft keine Aufrufer; ein handgefertigter Request an GenerateManifest kann die Kustomize-Optionen --enable-helm und --helm-command auf ein Skript aus einem Angreifer-Repository umbiegen. Wer den Port erreicht, erreicht eine Shell. Die Forscher meldeten die Lücke im Januar 2025 — rund 18 Monate später war sie ungepatcht. Die Eskalation geht weiter: Mit Codeausführung liest ein Angreifer das Redis-Passwort aus der Umgebung, vergiftet den Manifest-Cache und lässt den Application-Controller beim nächsten Sync die eigene Workload ausrollen — die Wiederauflage von CVE-2024-31989. Argo CD liefert NetworkPolicies mit, der offizielle Helm-Chart lässt sie aber standardmäßig deaktiviert (networkPolicy.create: false). Helm-basierte Installationen sind daher häufig ungeschützt.

Support-Abbruchkante als Risiko

Alle Oktober-Advisories tragen denselben Satz: „Argo CD 2.x und 3.0 bis 3.2 sind out of support und erhalten keinen Patch." Die betroffenen Codepfade reichen teils bis v0.9.0 (2018) zurück. Wer noch auf 2.x läuft, betreibt bekannte, publizierte 9.9-RCEs ohne Aussicht auf einen Fix — nur ein Upgrade auf 3.3 oder neuer hilft.

Was Teams jetzt tun sollten

Upgrade: v3.3.15, v3.4.10 oder v3.5.4 einspielen — 2.x und 3.0–3.2 bekommen keine Patches. Die signierten Release-Assets (Cosign, SLSA Level 3) nutzen.
Netz-Isolation: NetworkPolicies aktivieren. kubectl get networkpolicy -A sollte pro Komponente eine Policy zeigen; Repo-Server und Redis nur für Argo-CD-eigene Komponenten erreichbar lassen.
RBAC: Repository-Create/Update nicht an unvertrauenswürdige Nutzer vergeben — auch nicht projektweit.
Monitoring: Repo-Server auf unerwartete Shells und Git-Clones beobachten, Redis auf Zugriffe aus unerwarteten Quellen, Syncs ohne passenden Commit im Repository.
Prozesse: CVE-Feeds nicht als alleinige Wahrheit behandeln — drei der vier kritischen Oktober-Lücken sind dort unsichtbar. Release-Notes der eingesetzten Projekte regelmäßig lesen.

Fazit

Die Oktober-Welle zeigt zweierlei: Der Repo-Server ist zum Kronjuwel der GitOps-Angriffskette geworden, und die Schwere einer Lücke und ihre Sichtbarkeit in Scanner-Feeds sind unabhängige Variablen. GitOps-Teams sollten Argo CD wie Tier-Zero-Infrastruktur behandeln: Netzwerk-Policies als Standard, Least Privilege statt pauschaler Repository-Schreibrechte und Monitoring, das nicht auf CVE-Nummern wartet. Wer die vier Patches einspielt und seine Netzgrenzen schließt, hat die Welle hinter sich — wer nur auf Scanner vertraut, womöglich nicht.