Argo CD CVE-2026-77459: Delete-Hooks umgehen die Grenzen des AppProjects

TL;DR — 90 Sekunden

• Was: Argo CD legt PreDelete- und PostDelete-Hooks an, ohne Ziel, Namespace und erlaubte Ressourcen gegen das AppProject zu prüfen (CVE-2026-77459, CWE-863). Der application-controller erzeugt die Objekte dabei mit seinen eigenen Zugangsdaten.
• Schwere: CVSS 9.9 mit dem Vektor AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Drei weitere kritische Advisories im selben Release treffen den Repo-Server, darunter CVE-2026-113709, bei der mit aktivem --enable-helm schon das Recht get auf eine Application genügt, um dort Code auszuführen.
• Wen es trifft: Instanzen von 2.10.0 bis 2.14.21, 3.0.0 bis 3.3.14, 3.4.0 bis 3.4.9, 3.5.0 bis 3.5.3 und 3.6.0-rc1, auf denen Personen außerhalb des Plattform-Teams in überwachte Repositorys schreiben dürfen.
• Was zu tun ist: Auf 3.5.4, 3.4.10, 3.3.15 oder 3.6.0-rc2 aktualisieren. Für 2.x und 3.0 bis 3.2 gibt es keinen Patch, dort führt der Weg nur über ein Upgrade auf 3.3 oder neuer.
• Was vorher geschützt hätte: ein kleiner Kreis von Personen mit Schreibrecht auf überwachte Repositorys, eine Review-Regel für Delete-Hooks und --enable-helm nur dort, wo es wirklich gebraucht wird.
• Ausnutzung: Bis zum 31. Oktober steht keine der Lücken im CISA-KEV-Katalog, und Berichte über Angriffe sind nicht bekannt.

Delete-Hooks ohne Prüfung durch das AppProject

Ein AppProject begrenzt in Argo CD, wohin eine Application ausrollen darf. Es legt Ziel-Cluster, Namespaces und erlaubte Ressourcentypen fest, und bei einem normalen Sync prüft Argo CD jedes Objekt gegen diese Regeln. In Umgebungen mit mehreren Teams ist das AppProject damit die eigentliche Mandantengrenze.

Neben den normalen Manifesten kennt Argo CD Resource-Hooks, also Manifeste mit der Annotation argocd.argoproj.io/hook, die zu bestimmten Zeitpunkten eines Syncs laufen. Den Typ PostDelete gibt es laut Doku seit v2.10, er läuft, nachdem alle Ressourcen einer Application gelöscht sind. PreDelete läuft davor, und zwar nur, wenn die ganze Application gelöscht wird.

Genau hier lag der Fehler. Laut CVE-Beschreibung legt Argo CD PostDelete-Hooks an, ohne Ziel, Namespace und die Allow- und Deny-Listen für Ressourcen aus dem AppProject zu prüfen. Wer in das Repository einer Application schreiben kann, committet also einen Delete-Hook mit einem Ziel, das ihm eigentlich verboten ist. Wird die Application gelöscht, legt der application-controller das Objekt mit seinen eigenen Zugangsdaten an. Die übrigen Hook-Typen PreSync, Sync, PostSync und SyncFail prüft Argo CD weiterhin korrekt, die Lücke betrifft also nur den Pfad, der beim Löschen läuft.

PreDelete-Hooks sind genauso betroffen. Laut GHSA-Text kamen sie mit Version 3.3.0 hinzu und nutzen denselben Pfad wie PostDelete, der die Projektprüfung seit seiner Einführung in 2.10.0 nie angewendet hat. Version 2.9.22 und älter sind nicht betroffen. Das Advisory beschreibt außerdem, warum der Angriff so lange unbemerkt bleiben kann: Der Controller setzt den Delete-Finalizer, sobald er den Hook sieht, und die Application bleibt im Zustand Synced, bis jemand sie löscht. In einer typischen Installation hat der Controller weitreichenden Zugriff, sodass ein Mandant etwa ein clusterweites Objekt wie ein ClusterRoleBinding anlegen kann.

Betroffene Versionen und Voraussetzungen

Die Release Notes zu 3.5.4 führen alle acht Advisories auf. Die beiden, die in der Tabelle fehlen, sind als moderat eingestuft und betreffen den RBAC des Extension-Proxys sowie zu große OCI-Manifeste. Für Argo CD 2.x und 3.0 bis 3.2 gibt es laut Advisory zu CVE-2026-55797 keine Patches mehr.

Die Angaben zu den drei Repo-Server-Lücken stammen aus den CVE-Einträgen vom 20. Oktober, die alle denselben Vektor und damit CVSS 9.9 tragen. Bei CVE-2025-61560 ist die Lage dünner: Der CVE-Eintrag nennt weder Hersteller noch Fix und führt nur Version 3.0.6 auf, die Bewertung mit 8.1 stammt von CISA, Red Hat stuft die Lücke als moderat ein. Dass 3.5.4 sie behebt, entnehme ich den Release Notes.

Der Controller als Werkzeug des Angreifers

Beim Hook-Bypass arbeitet der application-controller für den Angreifer, denn er legt die Objekte mit seinen Zugangsdaten zum Ziel-Cluster an. Laut CVE-Beschreibung reicht das bis zu clusterweiten Ressourcen und gesperrten Namespaces, und auch Objekte, die ein Hook-Job selbst erzeugt, fallen darunter. Die Grenze setzen allein die Rechte des Controllers.

Unauffällig macht den Angriff vor allem der Zeitpunkt. Der Hook liegt im Repository und wirkt erst, wenn jemand die Application löscht, was Wochen nach dem Commit sein kann. Ein Review, das nur auf die Ergebnisse von Syncs schaut, bekommt davon nichts mit.

Die drei Repo-Server-Lücken zielen auf eine andere Stelle. Laut Release Notes führen zwei davon Befehle im Repo-Server aus, die dritte liest dort Dateien. Warum das schwer wiegt, sagt das Advisory zu CVE-2026-55797 ausdrücklich: Der Repo-Server kann die Git-, Helm- und OCI-Zugangsdaten anderer Teams lesen. Wer ihn übernimmt, kommt damit an die Quellen aller Teams.

CVE-2026-113709: Helm-Plugins aus dem Repository im Repo-Server

Eine der drei Repo-Server-Lücken hat inzwischen eine eigene CVE-Nummer bekommen und verdient einen genaueren Blick, weil sie mit sehr wenig Rechten auskommt. CVE-2026-113709 (GHSA-fw5c-w8rc-j7fx) wurde am 20. Oktober veröffentlicht und trägt CVSS 9.9 mit dem Vektor AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Betroffen ist laut CVE-Beschreibung jede Version ab 2.1.0 bis vor 3.3.15, 3.4.10, 3.5.4 und 3.6.0-rc2, aber nur dort, wo ein Operator für Kustomize-Builds --enable-helm eingeschaltet hat.

Der Mechanismus setzt an einer Eigenschaft von Helm an. Helm kennt sogenannte Downloader-Plugins, die Charts über eigene Protokolle laden, und sucht Plugins in seinem Daten-Verzeichnis. Kustomize kann Helm-Charts über helmCharts einbinden, und mit helmGlobals.configHome legt eine Kustomization fest, wo Helm seine Konfigurations- und Datenverzeichnisse findet. Zeigt dieser Pfad in das Repository, lädt Helm laut CVE-Beschreibung ein Downloader-Plugin aus <configHome>/.data/plugins, ohne dass es je installiert wurde, und führt dessen Programm im argocd-repo-server aus, sobald eine Chart-URL das Protokoll des Plugins nutzt. Der Befehl läuft als Benutzer des Repo-Servers und kann Repository-Zugangsdaten und alles andere lesen, was der Prozess sieht.

Bemerkenswert ist der zweite Zustellweg. Außer über einen Commit in ein Repository, das eine Application baut, lassen sich die Dateien über POST /api/v1/applications/manifestsWithFiles hochladen, den auch argocd app diff --local --server-side-generate nutzt. Dafür genügt laut Beschreibung das Recht get auf eine bestehende Application, ohne Update-, Sync- oder Schreibrechte auf das Repository. Lesezugriff auf Applications haben in vielen Instanzen fast alle Nutzer, etwa wenn policy.default in argocd-rbac-cm auf role:readonly steht und damit für jeden angemeldeten Nutzer gilt. Damit wird aus einer Lese- eine Ausführungsberechtigung im Repo-Server, und der hält die Git-, Helm- und OCI-Zugangsdaten aller Teams.

Den Ursprung nennt die CVE-Beschreibung ebenfalls. Kustomize 4.1.0 reichte helmGlobals.configHome erstmals an Helm durch, und Argo CD 2.1.0 hat mit PR #6059 auf Kustomize 4.1.2 gewechselt. Die Lücke entstand also nicht in Argo CD selbst, sondern durch eine neue Option einer eingebundenen Komponente, die ein Eingabefeld aus dem Repository bis in die Plugin-Suche von Helm durchreichte. Laut Release Notes zu 3.5.4 ignorieren Kustomize-Builds mit Helm seit dem Fix helmGlobals.configHome, Helm-Plugins aus diesem Verzeichnis laufen nicht mehr. Charts aus normalen http-, https- und oci-Repositorys sind davon nicht betroffen.

Für die Härtung folgt daraus vor allem eine Frage: Brauchst du --enable-helm wirklich? Argo CD setzt die Option über kustomize.buildOptions in der ConfigMap argocd-cm, und wo sie fehlt, ist die Instanz laut CVE-Beschreibung nicht betroffen. Wer Helm-Charts in Kustomize braucht, sollte dem Repo-Server zusätzlich per NetworkPolicy nur die tatsächlich genutzten Git-, Helm- und OCI-Quellen erlauben, damit ein ausgeführtes Plugin gelesene Zugangsdaten nicht beliebig nach außen schicken kann. Das leite ich aus dem Mechanismus ab und ist keine Vorgabe des Advisories. Die Grenze dieser Maßnahme zeigt die verwandte CVE-2026-113708: Dort kann der Angreifer laut CVE-Eintrag die Ausgabe seines Befehls über Fehlermeldungen der Manifest-Erzeugung zurückbekommen, ganz ohne ausgehende Verbindung. Eine Egress-Regel begrenzt also nur einen Teil des Schadens. Mit einer EPSS-Schätzung von 0,53 Prozent am 30. Oktober und ohne KEV-Eintrag ist die akute Gefahr kleiner als beim Hook-Bypass, der Fix steckt aber in denselben Versionen.

Update, Verhaltensänderungen und Übergangslösungen

Die einzige vollständige Behebung ist das Update auf 3.5.4, 3.4.10 oder 3.3.15, und wer Release Candidates testet, nimmt 3.6.0-rc2. Für 2.x und 3.0 bis 3.2 gibt es keinen Patch, dort führt der Weg nur über ein Upgrade auf 3.3 oder neuer.

Zwei Verhaltensänderungen solltest du vor dem Rollout prüfen. Laut Release Notes ignorieren Kustomize-Builds mit Helm nun helmGlobals.configHome, sodass Helm-Plugins aus diesem Verzeichnis nicht mehr funktionieren, während normale http-, https- und oci-Chart-Repositorys unberührt bleiben. Außerdem lehnt Argo CD OCI-Manifeste über 4 MiB jetzt ab.

Bis das Update eingespielt ist, lässt sich das Risiko je nach Lücke senken, aber nicht beseitigen. Für CVE-2026-77459 braucht der Angreifer Schreibzugriff auf ein Repository, das eine Application ausliest. Laut Advisory gibt es keine Einstellung, die Delete-Hooks der Projektprüfung unterwirft, solange sie in Gebrauch sind. Es empfiehlt deshalb, diesen Kreis klein zu halten, das Löschen von Applications zu beschränken und die Kubernetes-Rechte des application-controllers so weit einzuengen, dass ein Hook sensible Namespaces und APIs nicht erreicht. Für CVE-2026-113709 sind Instanzen ohne --enable-helm laut CVE-Beschreibung nicht betroffen. Wenn du keine Helm-Charts über Kustomize baust, entfernst du die Option deshalb aus kustomize.buildOptions in argocd-cm.

Für CVE-2026-55797 gibt es laut Advisory keine Einstellung, die Proxys für SSH-Repositorys erhält und zugleich den Shell-Aufruf entfernt. Es nennt stattdessen zwei Schritte: Unvertraute Nutzer dürfen Repositorys weder anlegen noch ändern, auch nicht über projektbezogene Repository-Rechte, und auf SSH-Repositorys oder passenden Credential-Templates sollte kein Proxy gesetzt sein. Für CVE-2026-113708 und CVE-2026-113672 nennen die CVE-Einträge keine Einstellung, die das Update ersetzt. Bei CVE-2026-113708 reicht es laut Eintrag auch nicht, Kustomize durch eine neuere Version zu ersetzen, weil der fehlende Optionstrenner beim Aufruf von git fetch bleibt. Beide Lücken lassen sich außerdem über manifestsWithFiles mit dem bloßen Leserecht auf eine Application ausnutzen, sodass auch ein enger Kreis von Schreibberechtigten hier wenig hilft.

Erkennung und Prüfung

Maßgeblich für die Verwundbarkeit ist die Version der Argo-CD-Komponenten im Cluster und nicht die der CLI. Liegt sie unter den Fix-Versionen, ist die Instanz betroffen. Für CVE-2026-113709 kommt hinzu, ob kustomize.buildOptions in argocd-cm die Option --enable-helm enthält.

Spuren eines Hook-Bypass findest du in den Repositorys deiner Applications. Durchsuche sie nach der Annotation argocd.argoproj.io/hook mit den Werten PreDelete oder PostDelete und vergleiche bei jedem Treffer Namespace und Ressourcentyp mit dem AppProject. Ein Hook mit fremdem Namespace oder clusterweitem Ressourcentyp ist verdächtig. Diese Suche ist meine eigene Ableitung und keine Vorgabe des Herstellers.

Für CVE-2026-55797 rät das Advisory, Repository- und Credential-Template-Secrets auf unerwartete proxy-Werte zu prüfen. Diese Secrets tragen laut Argo-CD-Doku das Label argocd.argoproj.io/secret-type mit dem Wert repository oder repo-creds. Auffällig ist ein Proxy an einer SSH-URL, besonders mit Sonderzeichen im Host.

IoCs hat das Argo-CD-Team nicht veröffentlicht. Bis zum 31. Oktober steht keine der Lücken im KEV-Katalog der CISA, und Berichte über Angriffe in freier Wildbahn habe ich nicht gefunden. EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen am 30. Oktober für CVE-2026-77459 auf 0,50 Prozent, für die drei Repo-Server-Lücken auf 0,53 bis 0,84 Prozent und für CVE-2026-55797 auf 1,87 Prozent.

Betreiberempfehlung

Akut handeln solltest du, wenn mehrere Teams oder Mandanten eine Argo-CD-Instanz teilen und AppProjects die Grenze zwischen ihnen ziehen. Dasselbe gilt, wenn Personen außerhalb des Plattform-Teams in überwachte Repositorys schreiben, Repositorys anlegen oder bei aktivem --enable-helm Applications lesen dürfen. Plane das Update dann vor dem nächsten regulären Wartungsfenster ein. Instanzen auf 2.x oder 3.0 bis 3.2 brauchen zusätzlich einen Upgrade-Pfad.

Beobachten genügt, wenn nur ein kleines, vertrautes Team in alle überwachten Repositorys schreibt und die Repositorys verwaltet. Das Update bleibt Pflicht, kann aber ins reguläre Fenster. Prüfe vorher die Änderungen bei Helm in Kustomize und bei OCI-Manifesten.

Am Ende gilt, was ich bei jeder Lücke sage: Patches und Updates gehören automatisiert. Wenn Renovate oder Dependabot neue Versionen des Argo-CD-Helm-Charts und der Images als Merge Request vorschlagen und die Pipeline sie gegen eine Staging-Instanz testet, ist ein Release wie 3.5.4 eine Sache von Stunden statt Wochen. Eine Karenzzeit für Routine-Updates schützt vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Gerade die Verhaltensänderungen dieses Releases zeigen den Nutzen, denn ein Build, der auf Helm-Plugins aus helmGlobals.configHome angewiesen war, scheitert dann in Staging und nicht in Produktion. Wer von Hand aktualisiert, bleibt dagegen leicht auf Versionen ohne Patch hängen, wie es Nutzern von 2.x und 3.0 bis 3.2 jetzt passiert, und muss dann einen großen Sprung über mehrere Minor-Versionen auf einmal wagen.

Fazit

Das Oktober-Release von Argo CD schließt acht Lücken, vier davon kritisch, und der Hook-Bypass trifft den Kern des Mandantenmodells. Eine Regel, die nur auf dem Hauptpfad greift, ist keine Grenze, und das gilt über Argo CD hinaus für jede Policy-Prüfung im Deployment. CVE-2026-113709 fügt eine zweite Lehre hinzu. Eine neue Option in einer eingebundenen Komponente kann ein Feld aus dem Repository bis an eine Stelle durchreichen, an der Code geladen wird, ohne dass sich am eigenen Code etwas geändert hat. Wer AppProjects als Trennung zwischen Teams nutzt, sollte deshalb jetzt aktualisieren und danach prüfen, wer in welche Repositorys schreiben darf und welche Build-Optionen der Repo-Server wirklich braucht.

Quellen

• GitHub: Argo CD Release v3.5.4 (6. Oktober 2026)
• GitHub Advisory GHSA-fmxq-cgp8-87wp (CVE-2026-77459)
• OSV: CVE-2026-77459
• OpenCVE: CVE-2026-77459
• OSV: GHSA-j6cw-g6p4-7hch (CVE-2026-55797)
• GitHub Advisory GHSA-9v9p-x54c-58gc
• GitHub Advisory GHSA-fw5c-w8rc-j7fx (CVE-2026-113709)
• OSV: CVE-2026-113709
• OSV: CVE-2026-113708
• OSV: CVE-2026-113672
• OpenCVE: CVE-2025-61560
• CISA: Known Exploited Vulnerabilities Catalog
• Argo CD Docs: Kustomizing Helm charts
• Argo CD PR #6059: upgrade to kustomize 4.1.2
• Kustomize PR #3784
• FIRST EPSS: CVE-2026-113709
• GitHub Advisory GHSA-m3vr-7329-44ww
• Argo CD Docs: Sync Phases and Waves
• Argo CD Docs: Declarative Setup
• Security Online: Four Critical Argo CD Vulnerabilities Fixed