Argo CD Flaw Lets Git Users Spawn Forbidden Kubernetes Resources During Deletion
A critical authorization flaw in Argo CD allows Git users to bypass project restrictions and create forbidden Kubernetes resources during application deletion events.

Key points
- Argo CD versions 2.10.0 through 3.6.0-rc2 contain a critical authorization bypass in PostDelete hooks.
- Attackers with Git write access can commit hooks that create resources in forbidden namespaces or clusters.
- Patches are available in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2 to restore standard authorization checks.
Argo CD, a declarative GitOps continuous delivery tool for Kubernetes, contains a critical authorization bypass affecting its PostDelete resource hooks. According to the National Vulnerability Database, versions from 2.10.0 up to specific patched releases fail to apply standard AppProject destination and resource authorization checks during these specific lifecycle events.
This omission allows users with write access to an Application's Git repository to define delete hooks that target forbidden namespaces, servers, or resource kinds. When the associated Application is deleted, the application-controller processes these hooks using its destination-cluster credentials, potentially creating cluster-scoped resources or objects in disallowed namespaces.
The risk
The vulnerability, tracked as CVE-2026-77459, carries a CVSS score of 9.9, rated as critical by the NVD. The core issue stems from the application-controller skipping the cluster-scoped and namespaced resource allow/deny lists that normally govern synchronization operations. While PreSync, Sync, PostSync, and SyncFail hooks continue to enforce standard project checks, PostDelete hooks operate without these safeguards. This discrepancy means an attacker can bypass strict project policies by embedding malicious instructions within a deletion workflow, leveraging the controller's elevated permissions to execute actions that would otherwise be denied during standard application updates.
Who is exposed
Any organization running vulnerable versions of Argo CD is exposed to this risk. The affected range includes versions 2.10.0 through 2.14.21, as well as 3.0.0 through 3.3.14, 3.4.0 through 3.4.9, and 3.5.0 through 3.5.3. Additionally, pre-release version 3.6.0-rc2 is affected. Environments where developers or CI/CD pipelines have write access to Git repositories hosting Argo CD Application manifests are particularly at risk, as they can inject the malicious hooks required to trigger the unauthorized resource creation.
Cost and compliance
The source material does not provide specific details regarding financial costs, regulatory fines, or compliance implications associated with this vulnerability. The NVD record focuses exclusively on the technical mechanics of the authorization bypass and the affected software versions. No information is available in the provided sources regarding potential data breaches, service disruptions, or specific regulatory frameworks that might be impacted by the creation of unauthorized Kubernetes resources.
What to watch
Security teams should immediately audit their Argo CD installations to determine if they are running any of the affected versions listed in the NVD record. Organizations should verify that their Git repositories hosting Application manifests are protected by strict access controls, limiting write permissions to trusted personnel or automated pipelines. Monitoring for unexpected resource creation events, particularly those occurring during application deletion workflows, can help identify potential exploitation attempts before they escalate into broader cluster compromise.
Signals worth monitoring
Teams usually detect this type of activity by reviewing Kubernetes audit logs for resource creation events that lack corresponding application synchronization records. Check whether any new pods, services, or cluster-scoped objects appear immediately after an Argo CD Application is deleted, especially if those resources reside in namespaces excluded by project policies. Look for anomalies in the application-controller logs where PostDelete hooks are processed without the usual authorization validation steps. Investigate any Git commits that introduce new hook definitions targeting sensitive or restricted resource kinds, as these often precede the exploitation event.
What to do and how to stay safe: Argo CD
- Update Argo CD to version 3.3.15, 3.4.10, 3.5.4, or 3.6.0-rc2 to apply the vendor-provided fix for this authorization bypass.
- Review recent Git commits in Argo CD Application repositories for any newly added PostDelete hooks that target sensitive namespaces or resource types.
- Audit Kubernetes clusters for any unauthorized resources created during recent application deletion events, particularly cluster-scoped objects or resources in forbidden namespaces.
- Restrict write access to Git repositories hosting Argo CD manifests to reduce the attack surface for potential hook injection.
Step-by-step guide: Vulnerability Prioritization: Fix What Actually Matters First
General security guidance from the SecOps Signal newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which Argo CD versions are affected by CVE-2026-77459?
Versions 2.10.0 through 2.14.21, 3.0.0 through 3.3.14, 3.4.0 through 3.4.9, 3.5.0 through 3.5.3, and 3.6.0-rc2 are affected.
Is there a patch available for this vulnerability?
Yes, the issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.
How does this vulnerability allow unauthorized resource creation?
PostDelete hooks skip standard AppProject authorization checks, allowing the application-controller to create resources in forbidden namespaces or clusters using its credentials.



