On this page (7 sections)
A critical authorization flaw affects Argo CD, the GitOps delivery tool for Kubernetes. The GitHub advisory explains that resource hooks which run when an Application is deleted (PreDelete and PostDelete) are created without the AppProject restrictions that normally fence an Application in. It is tracked as CVE-2026-77459 with a CVSS score of 9.9.
Platform teams that run Argo CD for several tenants, and rely on AppProjects as the boundary between them, should read on. Fixed releases exist only for 3.3 and newer, so older installs need a version upgrade rather than a small patch.
What happened
Before Argo CD creates resources during a sync, it checks the Application's AppProject. That project defines which destination namespaces and servers are allowed, and which cluster-scoped and namespaced resources may be created or must be denied, including by resource name. According to the advisory, hooks of type PreDelete and PostDelete never go through this check. They are created when the Application is deleted, and they run with the application-controller's credentials on the destination cluster.
The advisory was published on October 7, 2026, appeared in the National Vulnerability Database on October 13 and in the GitHub Advisory Database on October 15. That advisory is the only primary source in our research, so anything beyond it should be treated as unconfirmed.
How the bypass works
The weakness class is incorrect authorization (CWE-863). A rule is enforced on one route to a result but forgotten on another route to the same result. Here the rule is the project policy, and the forgotten route is the code that creates delete hooks. Picture an office where the front desk checks every visitor but a side door stays unlocked.
The advisory describes the attacker as someone who can push to the Git repository that an Application syncs from. They commit a hook that targets a namespace, group, kind or name the AppProject would reject on sync. The controller adds a delete finalizer once it sees the hook, and the Application continues to show as Synced. Nothing happens until somebody deletes the Application, at which point the hook is created.
The reach of the hook is limited by what the application-controller itself can do on the destination cluster. The advisory says that in a typical install this access is broad, so a tenant could create a cluster-scoped object such as a ClusterRoleBinding, or an object in a namespace the project does not permit. Two details affect cleanup:
- A hook with no deletion policy is removed once it succeeds, while a policy that skips removal on success leaves the object in the cluster.
- A hook such as a Job may create secondary objects that Argo CD does not remove.
Hooks of type PreSync, Sync, PostSync and SyncFail continue to use the normal project check and are outside this issue.
Who is affected
Per the advisory, every release from 2.10.0 onward is affected, including all currently supported ones. PostDelete hooks first shipped in 2.10.0 and PreDelete hooks first shipped in 3.3.0. Version 2.9.22 and earlier are not affected.
| Branch | Vulnerable | Fixed |
|---|---|---|
| 2.x | 2.10.0 through 2.14.21 | None (out of support) |
| 3.0 to 3.2 | All releases from 3.0.0 (below 3.3.15 on the 3 line) | None (out of support); move to 3.3 or newer |
| 3.3 | 3.3.x below 3.3.15 | 3.3.15 |
| 3.4 | 3.4.0 up to 3.4.10 | 3.4.10 |
| 3.5 | 3.5.0 up to 3.5.4 | 3.5.4 |
| 3.6 | 3.6.0-rc1 | 3.6.0-rc2 |
Real-world risk depends on who can write to your repositories. If every committer on a single-team cluster already holds cluster admin rights, the flaw adds little. If a platform team gives separate tenants restrictive AppProjects and treats them as a security boundary, that boundary can be crossed.
How to check your exposure
Start with the version. This read-only command prints each pod in the argocd namespace with its container images. Compare the image tags with the fixed versions above, and change the namespace if you installed Argo CD elsewhere.
kubectl get pods -n argocd -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'Then look at who holds broad rights. The advisory's workarounds concern people who can push to Application repositories, people who can delete Applications, and the controller's own access. This read-only command lists cluster role bindings so you can spot subjects with wide permissions, including the Argo CD controller.
kubectl get clusterrolebindings -o wideAlso scan recent commits in repositories behind restrictive AppProjects for hook annotations nobody recognizes. A malicious delete hook has to be committed to Git before it can be used.
What to do now
Upgrading is the real fix. The advisory states that no configuration setting applies the project check to delete hooks while those hooks remain in use. The patched releases perform the same destination and resource checks as a sync before creating a PreDelete or PostDelete hook.
0 of 7 done
Detection and monitoring afterwards
The sources report no exploitation, so there is no known indicator list. Watch instead for what abuse would look like: new cluster-scoped objects, or objects in disallowed namespaces, appearing around the time an Application is deleted, and deletions performed by people who rarely delete Applications. Kubernetes audit logs and Argo CD's own logs are the natural places to look.
Consider requiring a second reviewer for commits that add or change hook annotations in tenant repositories, using the code review rules of your Git host.
If public websites or APIs run on these clusters, keep an outside view as well. Webforta Monitor tracks uptime, certificates, DNS and header changes, and the free SSL checker gives a quick look at a certificate. Neither replaces patching your delivery pipeline. For wider basics, see small business website security.
Timeline
- December 2023: commit introducing PostDelete hooks, first released in 2.10.0, per the advisory.
- December 2025: commit adding PreDelete hooks, first released in 3.3.0.
- October 7, 2026: advisory published in the argoproj/argo-cd repository.
- October 13, 2026: published by the National Vulnerability Database.
- October 15, 2026: published to the GitHub Advisory Database, reviewed and last updated.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.