CVE-2026-77459 in Argo CD
Summary
by MITRE • 10/13/2026
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. From 2.10.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, Argo CD creates PostDelete resource hooks without applying the AppProject destination and resource authorization checks used during ordinary synchronization. The omitted checks include cluster-scoped and namespaced resource allow/deny lists. A user who can write to an Application's Git repository can commit a delete hook targeting a forbidden namespace, server, group, kind, or resource name, and deletion of the Application causes the application-controller to create that resource with its destination-cluster credentials. The reachable impact is bounded by the controller's cluster access but can include cluster-scoped resources, disallowed namespaces, persistent hook objects, and secondary objects created by a hook Job. PreSync, Sync, PostSync, and SyncFail hooks continue to use the normal project checks. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
Argo CD serves as a declarative GitOps continuous delivery tool designed for Kubernetes environments, facilitating the automated synchronization of application states from version control systems to cluster targets. A critical security vulnerability was identified in specific versions ranging from 2.10.0 through various releases including 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2. The core issue stems from an inconsistency in how resource authorization checks are applied during different phases of the synchronization lifecycle. Specifically, while standard synchronization operations enforce strict AppProject destination and resource authorization policies, PostDelete resource hooks bypass these essential security controls. This discrepancy creates a significant gap in access control enforcement that can be exploited by attackers with write permissions to Application repositories.
The technical flaw lies in the omission of cluster-scoped and namespaced resource allow or deny lists when processing PostDelete hooks. In normal synchronization workflows, Argo CD validates whether the target resources are permitted within the configured AppProject constraints before executing any changes. However, during the deletion phase triggered by a PostDelete hook, this validation step is skipped entirely. Consequently, if an attacker can commit code to an Application's Git repository that defines such a hook, they can specify targets for forbidden namespaces, unauthorized servers, prohibited resource groups, kinds, or specific resource names. When the associated Argo CD application is deleted, the controller executes these hooks using its own destination-cluster credentials rather than restricting them by project policies.
The operational impact of this vulnerability is substantial and directly tied to the privileges held by the Argo CD controller within the Kubernetes cluster. An attacker can leverage this flaw to delete or manipulate resources that are explicitly denied by security policies, including critical cluster-scoped objects such as ClusterRoles, PersistentVolumes, or Namespace configurations. Furthermore, because PostDelete hooks often involve executing Jobs, the vulnerability allows for the creation of persistent hook objects and secondary workloads within disallowed namespaces. This effectively circumvents namespace isolation boundaries, potentially leading to privilege escalation, data exfiltration, or denial of service by disrupting critical infrastructure components that should have been protected from unauthorized modification via GitOps workflows.
It is important to note that this authorization bypass does not affect other hook types such as PreSync, Sync, PostSync, and SyncFail hooks, which continue to utilize the standard project checks and maintain proper access control boundaries. This selective vulnerability highlights a specific edge case in the lifecycle management of Argo CD applications rather than a systemic failure across all operations. The risk is primarily confined to scenarios where an attacker has write access to the Git repository containing Application definitions and can trigger application deletion events, thereby activating the unchecked PostDelete hooks.
To mitigate this vulnerability, organizations must upgrade their Argo CD installations to patched versions immediately. The issue was resolved in releases 3.3.15, 3.4.10, 3.5.4, and version 3.6.0-rc2. Until an upgrade is feasible, administrators should enforce strict access controls on Git repositories hosting Argo CD Application manifests to prevent unauthorized users from committing malicious hook definitions. Additionally, implementing robust RBAC policies within Kubernetes can help limit the blast radius if such a hook were executed by restricting the permissions of the service accounts used by Argo CD controllers. This incident underscores the importance of consistent security policy enforcement across all operational phases in GitOps tools and aligns with CWE-284 regarding improper access control, as well as ATT&CK techniques related to privilege escalation and lateral movement within containerized environments.