Wer sein Homelab oder seine Firmen-Infrastruktur per GitOps mit Argo CD steuert, sollte jetzt genau hinschauen: Das Projekt hat am 7. Oktober 2026 gleich vier kritische Sicherheitslücken veröffentlicht — jede einzelne mit der höchstmöglichen praktischen CVSS-Bewertung von 9,9.
WAS KAPUTT IST: Drei Wege in den Repo-Server, ein Weg um die Regeln herum
Drei der vier Lücken erlauben es Angreifern, Befehle auszuführen oder Dateien zu lesen innerhalb des argocd-repo-server — also genau der Komponente, die Git-Repositories klont und Manifeste rendert. Betroffen sind die Verarbeitung von Kustomize-Helm-Konfigurationen (ab Version 2.1.0), Kustomize-Remote-Referenzen (ab 2.7.0) und das Einlesen von Jsonnet-Dateien (ab 0.9.0). Laut Advisory reicht es bei einem der Angriffswege aus, dass ein Nutzer lediglich Lese-Zugriff auf eine bestehende Application besitzt — ein vergleichsweise niedriges Einstiegsniveau für eine Lücke dieser Schwere.
Die vierte Lücke, mit der eigenen CVE-Nummer CVE-2026-77459, funktioniert anders: AppProjects legen fest, wohin eine Application überhaupt deployen darf. Die PreDelete- und PostDelete-Hooks von Helm haben diese Prüfung bislang aber umgangen. Wer Schreibrechte auf das zugrunde liegende Git-Repository hat, kann einen entsprechenden Hook committen, den das Projekt eigentlich ablehnen würde. Löscht jemand die Application, führt Argo CD diesen Hook dann mit den Rechten des Controllers aus — und damit potenziell weit über die eigentlich erlaubten Grenzen hinaus.
WIE GEFÄHRLICH DAS WIRKLICH IST
Eine CVSS-Bewertung von 9,9 gehört zu den höchsten, die in der Praxis vergeben werden. Wichtig zur Einordnung: Das Argo-CD-Projekt selbst meldet keine bekannte aktive Ausnutzung und auch keinen öffentlich kursierenden Exploit-Code. Das Risiko ist also real und sollte ernst genommen werden — ein akuter Notfall mit laufenden Angriffswellen ist es nach aktuellem Stand aber nicht.
Trotzdem macht die Kombination aus den vier Lücken deutlich, warum Sicherheitsforscher GitOps-Infrastruktur zunehmend als „Tier Zero“ einstufen: Wer Zugriff auf den Repo-Server oder die Deployment-Pipeline bekommt, kontrolliert im Zweifel den gesamten Kubernetes-Cluster, der daran hängt — nicht nur eine einzelne Anwendung.
SO SCHÜTZT DU DEINEN CLUSTER
Die gepatchten Versionen stehen bereit: 3.5.4, 3.4.10, 3.3.15 sowie der Release Candidate 3.6.0-rc2 für alle, die bereits auf der kommenden Hauptversion testen. Wer nicht sofort aktualisieren kann, nennt das Projekt mehrere Zwischenlösungen:
- Helm innerhalb von Kustomize deaktivieren, falls diese Kombination nicht zwingend gebraucht wird
- Jsonnet-Unterstützung deaktivieren, wenn keine Jsonnet-Manifeste im Einsatz sind
- Kustomize auf eine ältere, nicht betroffene Version zurückstufen
- Schreibzugriff auf die Git-Repositories einschränken, die von Argo CD synchronisiert werden — das entschärft vor allem die AppProject-Umgehung
Für Homelab-Betreiber mit kleineren Kubernetes-Clustern ist die praktikabelste Lösung in den meisten Fällen schlicht das Update auf die passende Patch-Version — die Workarounds sind vor allem für Umgebungen gedacht, in denen ein sofortiges Upgrade aus betrieblichen Gründen nicht möglich ist.
WARUM DAS AUCH FÜRS HOMELAB ZÄHLT
Argo CD ist längst nicht mehr nur ein Enterprise-Werkzeug. Gerade in Self-Hosting- und Homelab-Kreisen hat sich GitOps als bequemer Weg etabliert, Kubernetes-Deployments aus einem Git-Repository heraus zu steuern — oft mit denselben Grundrechten, mit denen auch produktive Firmen-Cluster laufen. Wer seinen Cluster so betreibt, sollte die Update-Pflicht nicht auf die lange Bank schieben, nur weil bislang keine Angriffe bekannt sind.