Argo CD: PreDelete/PostDelete Resource Hooks Bypass AppProject Restrictions (CVE-2026-77459)

What happened

Argo CD's maintainers published GHSA-fmxq-cgp8-87wp disclosing that PreDelete and PostDelete resource hooks do not go through the AppProject check that normally governs destination namespaces/servers and cluster-scoped and namespaced resource allow/deny lists. PreSync, Sync, PostSync, and SyncFail hooks are unaffected. According to the advisory, PostDelete hooks have lacked this check since their introduction in v2.10.0 (2023-12-18), and PreDelete hooks inherited the same gap when added in v3.3.0 (2025-12-05) — so every currently supported release is affected; v2.9.22 and earlier predate these hooks and are not. CVSS is listed at 9.9, and the advisory notes the exploit status as having a public PoC.

Why it matters

Per the advisory, a user with Git push access to a repo an Application syncs from can commit a hook with a namespace, group, kind, or name the AppProject would normally refuse. The hook isn't created at sync time — the controller just adds a delete finalizer — so the Application sits in a normal Synced state until someone deletes it, at which point the hook is created using the application-controller's own credentials against the destination cluster. Since that service account's cluster access is often broad in typical installs, the advisory states this can let a tenant create cluster-scoped objects (e.g., a ClusterRoleBinding) or objects outside namespaces the project was supposed to restrict them to — effectively an AppProject privilege-isolation bypass in multi-tenant Argo CD environments.

What defenders should do now

• Patch: the advisory lists fixes in v3.6.0-rc2, v3.5.4, v3.4.10, and v3.3.15. Argo CD 2.x and 3.0–3.2 are out of support and will not receive a fix — upgrade to a patched 3.3+ release.
• In the interim, the advisory states there is no config option that extends the project check to delete hooks, so mitigation is procedural: restrict Git write access to repos backing restrictive AppProjects, limit who can delete Applications (since deletion is what triggers these hooks), and tighten the application-controller's own Kubernetes RBAC so a rogue hook has less to reach even if one runs.
• Hunting angle: review Application manifests/Git history for PreDelete/PostDelete hooks targeting resources outside an AppProject's allowed namespaces or kinds, and audit recent Application deletions for cluster-scoped objects (e.g., ClusterRoleBindings) that appeared around the same time but weren't part of the normal sync manifest.

Developing intel

This is same-day advisory intel; full technical detail, patch diffs, and any further exploitation reporting should be confirmed against the primary source as it's updated. See the original GHSA advisory: GHSA-fmxq-cgp8-87wp.