Argo CD EUVD-2026-105227

Requires an authenticated Argo CD account holding at least Application 'get' permission on an existing directory-type Application - notably NOT Application update, sync, or repository write access - because the POST /api/v1/applications/manifestsWithFiles upload path (also reachable via argocd app diff --local --server-side-generate) accepts attacker-supplied .jsonnet. Argo CD's default role:catch-all policy grants get to every authenticated user, lowering the bar substantially on multi-tenant installs. Alternatively, an attacker with write access to a Git repository backing an Application can commit the malicious .jsonnet, since directory Applications evaluate every .jsonnet file in the directory. The flaw only applies where .jsonnet rendering is reachable and is limited to Argo CD versions 0.9.0 through those preceding 3.3.15/3.4.10/3.5.4/3.6.0-rc2; secrets written to generated Kubernetes Secrets are redacted, so the attacker must route stolen data through a non-Secret resource such as a ConfigMap to read it back.

This is a genuine high-priority issue, not a CVSS-inflated one. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) aligns with the description: a network-reachable repo-server endpoint reachable by any authenticated Argo CD user with only Application 'get' permission (PR:L), requiring no user interaction and no special timing (AC:L). The scope change (S:C) is well justified because arbitrary file read lets the attacker steal projected service-account tokens, mounted private keys and repository credentials - secrets belonging to other security authorities that enable lateral movement across the Kubernetes cluster. The confidentiality and availability impacts are strongly supported (file disclosure plus /dev/zero memory-exhaustion DoS); the integrity (I:H) claim is weaker since the primitive is read/disclosure rather than modification. No EPSS score, KEV listing, or POC indicator is present in the input, so there is no signal of active exploitation or widespread automated attacks - this is a vendor-reported (GitHub Security Advisory) flaw. The low barrier to entry (default role:catch-all grants get, and the upload path needs neither update, sync, nor repo write access) makes exploitation realistic for any tenant on a shared Argo CD instance, which is the primary driver of urgency rather than any observed in-the-wild activity.

A tenant with only read (get) access to an existing directory-type Application on a multi-tenant Argo CD instance crafts a .jsonnet file that uses importstr on an absolute path such as /var/run/secrets/kubernetes.io/serviceaccount/token or a mounted repository credential, and places the imported content inside a ConfigMap. They submit it via POST /api/v1/applications/manifestsWithFiles (or argocd app diff --local --server-side-generate); the repo-server evaluates the file and returns the harvested secret in the rendered manifest. No public exploit identified at time of analysis, though the technique is fully described in the vendor advisory.