GPU VulnDB

Database/Container, Kubernetes & orchestration

Argo CD: PostDelete hooks skip AppProject destination and resource allow/deny checks

CVSS 9.9CVE-2026-77459Container, Kubernetes & orchestrationcurated

Impact

Argo CD creates PostDelete hook resources without the AppProject destination and resource authorization checks it applies during normal sync, so the allow/deny lists for cluster-scoped and namespaced kinds are not enforced on that path. Anyone who can commit to an Application's Git repository can add a delete hook targeting a namespace, cluster, group, kind or resource name the project forbids; deleting the Application then makes the application-controller create it using the destination cluster's credentials. On a shared GPU cluster where Argo CD holds broad cluster-admin-like access, that is a path from repository write to cluster-scoped object creation - a hook Job can in turn create further objects, so a tenant confined to one namespace by AppProject policy can reach outside it. PreSync, Sync, PostSync and SyncFail hooks are unaffected; only PostDelete bypasses the checks.

Who can reach it

A user with write access to an Application's Git repository (no Argo CD API privileges needed beyond whatever triggers the Application deletion). Reachable impact is bounded by the application-controller's own RBAC on the destination cluster.

What to do

Upgrade Argo CD to 3.3.15, 3.4.10, 3.5.4 or 3.6.0-rc2. This is a control-plane component upgrade - rolling the application-controller and repo-server deployments, with no GPU node disruption; in-flight syncs pause briefly. Until then, review PostDelete hooks in managed repositories and tighten the controller's cluster RBAC so the blast radius matches the AppProject intent.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.