Key points
- Argo CD versions 2.10.0 through 3.6.0-rc2 contain a critical authentication bypass in PostDelete hooks.
- The flaw allows users with Git write access to target forbidden namespaces or cluster-scoped resources.
- Patches are available for versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.
Argo CD versions 2.10.0 through 2.14.21, 3.0.0 through 3.3.14, 3.4.0 through 3.4.9, and 3.5.0 through 3.5.3 are affected by a critical vulnerability. The issue stems from missing authorization checks during the execution of PostDelete resource hooks. Patches have been released for versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, according to the National Vulnerability Database.
In plain English
When an Argo CD application is deleted, it can trigger cleanup scripts known as PostDelete hooks. In affected versions, these hooks do not respect the AppProject destination and resource authorization rules that apply during normal synchronization. This means the standard allow and deny lists for clusters and namespaces are ignored. Consequently, the application controller creates resources using its own credentials, regardless of project restrictions.
The background
The vulnerability is classified as CWE-863 and carries a CVSS score of 9.9, rated as critical. It affects Argo CD, a declarative GitOps continuous delivery tool for Kubernetes. The flaw allows a user who can write to an Application's Git repository to commit a delete hook targeting a forbidden namespace, server, group, kind, or resource name. This bypasses the security boundaries intended to limit what each project can modify within the cluster.
What changes now
The reach of the attack is limited by the permissions of the application-controller itself. However, this can still 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 normal project checks and are not affected by this specific issue. Users must upgrade to the patched versions to restore proper authorization enforcement for PostDelete hooks.
Who needs to act first
Teams usually prioritize systems exposed to external networks or those with high-privileged application controllers. Check whether your Argo CD instances run on affected versions and assess the risk of unauthorized Git access. Roll out fixes in test environments first to ensure stability. Back up current configurations before upgrading. Reduce exposure by restricting write access to Git repositories containing Argo CD applications until patches are applied.
What to do and how to stay safe: Argo CD
- Verify if your Argo CD version falls within the affected ranges listed in the advisory.
- Restrict write permissions to Git repositories that define Argo CD applications to limit attack surface.
- Monitor cluster logs for unexpected resource creation or deletion events triggered by PostDelete hooks.
- Plan upgrades to patched versions 3.3.15, 3.4.10, 3.5.4, or 3.6.0-rc2 as soon as possible.
Step-by-step guide: 7 Configuration Errors That Expose Systems to Zero-Day Exploits
General security guidance from the Vuln Post newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which Argo CD versions are vulnerable to this PostDelete hook bypass?
Versions 2.10.0 through 2.14.21, 3.0.0 through 3.3.14, 3.4.0 through 3.4.9, and 3.5.0 through 3.5.3 are affected.
Are other hook types like PreSync or PostSync also vulnerable?
No, PreSync, Sync, PostSync, and SyncFail hooks continue to use normal project authorization checks.
Is there a fix available for this critical vulnerability?
Yes, the issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.
