Source: GitLab Advisory Database

A critical authorization flaw in Argo CD, tracked as CVE-2026-77459 and rated CVSS 9.9, allows a user who can push commits to an Application’s Git repository to create resources that the AppProject configuration should forbid. During ordinary syncs, Argo CD checks the AppProject’s destination namespaces and servers, cluster-scoped allow and deny lists, and namespaced resource rules before creating anything. PreDelete and PostDelete hooks skip those checks entirely, and when an Application is deleted the controller creates the hook resources using its own credentials on the destination cluster.

What an attacker can reach

The reachable impact is bounded by the application-controller’s access, which is broad in a typical installation. A tenant with write access to a Git repository can create cluster-scoped objects such as a ClusterRoleBinding, or objects in namespaces the project does not allow. Because the hook only fires when someone deletes the Application, the malicious resource can sit dormant in Git until an unrelated cleanup triggers it. All versions from 2.10.0 onward are affected, including every currently supported release.

What to do this week

Upgrade to Argo CD 3.3.15, 3.4.10, 3.5.4 or 3.6.0-rc2, which apply the missing project checks to delete hooks. In the meantime, restrict who can push to the repositories your Applications sync from, and review the RBAC of your application-controller, because narrowing its cluster permissions limits what a bypass can achieve. GitOps is built on the idea that Git access is deployment access, and this flaw is a sharp reminder to treat repository write permissions as production-critical.

If you run Argo CD in production and want help upgrading safely, tightening controller permissions or reviewing your Kubernetes security posture, contact Excello Digital at https://excello.digital/contact/. We help European DevOps teams ship fast without shipping their cluster to attackers.