Argo CD EUVD-2026-98917

Requires: (1) write access to the Git repository backing an Argo CD Application (the PR:L privilege), (2) the ability to author a PreDelete or PostDelete resource hook manifest that pins a forbidden metadata.namespace, server, group, kind, or resource name, and (3) that the Application subsequently be deleted, which causes the application-controller to create the hooked resource with the destination cluster's credentials. Limiting factors that reduce real-world risk: only PreDelete/PostDelete hooks are affected - PreSync, Sync, PostSync, and SyncFail hooks still enforce the normal AppProject checks; the achievable impact is bounded by the application-controller's own cluster RBAC on the destination cluster; and the flaw is only meaningful where AppProject destination/resource allow-deny lists are relied upon as a security boundary (typically multi-tenant deployments). Affected versions are 2.10.0 through the releases immediately preceding 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.

The vendor CVSS of 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) is credible for this authorization-bypass (CWE-863): the scope change (S:C) correctly captures that the application-controller acts with destination-cluster credentials, letting an attacker escape the AppProject authorization boundary and affect resources the user was never permitted to touch. However, the AV:N/PR:L framing understates the real preconditions - exploitation is not a simple remote request but requires write access to an Application's Git repository AND that the Application subsequently be deleted, so the practical attack complexity is higher than AC:L implies. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so exploitation status is: no public exploit identified at time of analysis - this is a high-CVSS issue driven by potential impact rather than any evidence of active or at-scale exploitation. The dominant risk factor is the insider/supply-chain angle: in multi-tenant Argo CD deployments where Git write access is delegated to teams but AppProject restrictions are the trust boundary, this flaw silently voids that boundary for PostDelete and PreDelete hooks only (PreSync/Sync/PostSync/SyncFail still enforce checks). Realistic impact is bounded by the controller's own cluster RBAC, which should temper the 9.9 in environments that scope controller credentials tightly.

In a multi-tenant Argo CD setup, a developer who can commit to an Application's Git repository adds a PostDelete (or PreDelete) hook manifest pinned to a forbidden namespace such as kube-system or a cluster-scoped kind the AppProject denies. When that Application is deleted, the application-controller creates the hook resource using the privileged destination-cluster credentials, bypassing the AppProject allow/deny lists and letting the attacker run a Job or plant a persistent object in an off-limits location. No public exploit code is identified at time of analysis, though the vendor test suite demonstrates the forbidden-namespace and forbidden-kind cases.