CVE-2026-113709

In Argo CD from 2.7.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, Kustomize passes ref or version query values from remote resource, base, or component URLs to git fetch without an end-of-options separator. A leading-hyphen value can be parsed as --upload-pack and execute a command inside argocd-repo-server when the remote uses a local transport such as file://. Git does not run the supplied command for an https:// remote. The local transport does not leave the pod, so blocking repo-server egress does not prevent the execution. The command runs as the repo-server user, can read repository credentials and other process-accessible data, and can return output through manifest-generation errors. An attacker can commit a Kustomization to a Git repository that an Application builds or upload files through POST /api/v1/applications/manifestsWithFiles, also exposed by argocd app diff --local --server-side-generate. The upload path requires only Application get permission on an existing Application, without Application update or sync permission or repository write access. Kustomize 5.0.0 introduced acceptance of file://, whereas 4.5.7 rejects that transport; replacing the affected Kustomize with a newer version alone does not correct the missing option separator. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.

In Argo CD from 0.9.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, the repo-server evaluates .jsonnet files with an importer that does not confine import, importstr, or importbin to the repository root. Absolute paths, parent-directory traversal, and repository symlinks can open any file readable by the repo-server, including /proc/self/environ, projected service-account tokens, mounted private keys, and repository credentials. Although generated Secrets are redacted, placing imported contents in a ConfigMap returns the data to the caller. Using importstr on a non-terminating device such as /dev/zero can exhaust repo-server memory. An attacker can commit a .jsonnet file to a Git repository used by an Application or upload the file through POST /api/v1/applications/manifestsWithFiles, also exposed by argocd app diff --local --server-side-generate. Directory applications evaluate every .jsonnet file in the application directory. The upload path requires only Application get permission on an existing directory Application, without Application update or sync permission or repository write access. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.

Argo CD from 2.10.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2 creates PostDelete resource hooks without applying the AppProject destination and resource authorization checks used during ordinary synchronization. A user who can write to an Application's Git repository can commit a delete hook targeting a forbidden namespace, server, group, kind, or resource name, and deletion of the Application causes the application-controller to create that resource with its destination-cluster credentials. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.

In Argo CD versions 3.2.0 to 3.2.10 and 3.3.0 to 3.3.8, there is a missing authorization and data-masking gap in the ServerSideDiff endpoint. This allows an attacker with read-only access to extract plaintext Kubernetes Secret data from etcd via the Kubernetes API server's Server-Side Apply dry-run mechanism.

Argo CD versions 2.9.0-rc1 through 2.14.19, 3.0.0-rc1 through 3.2.0-rc1, 3.1.6 and 3.0.17 have a vulnerability where, when webhook.azuredevops.username and webhook.azuredevops.password are not set in the default configuration, the /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty. The slice index [0] is accessed without a length check, causing an index-out-of-range panic. A single unauthenticated HTTP POST is enough to kill the process. This issue is resolved in versions 2.14.20, 3.2.0-rc2, 3.1.8 and 3.0.19.

Argo CD versions 2.13.0 through 2.13.8, 2.14.0 through 2.14.15, 3.0.0 through 3.0.12, and 3.1.0-rc1 through 3.1.1 allow API tokens with project-level permissions to retrieve sensitive repository credentials (usernames, passwords) through the project details API endpoint. The vulnerability also affects tokens with global project get permissions. Fixed in versions 2.13.9, 2.14.16, 3.0.14, and 3.1.2.

Argo CD repo-server is vulnerable to command injection when it clones, tests, or fetches an SSH Git repository configured with a proxy URL. The proxy host and port are embedded in an SSH ProxyCommand executed through a shell without neutralizing shell metacharacters. A user who can create or update a repository or repository credential template can execute commands in the repo-server and access its Git, Helm, and OCI credentials.

A race condition vulnerability in the SessionManager of Argo CD v3.0.6 allows attackers to bypass rate limiting and perform a brute force attack via repeated crafted requests.

A vulnerability in Argo CD allows users with application write access to set link.argocd.argoproj.io/* annotations whose pipe-separated values are rendered as anchor href values in the Summary tab URLs section without URL validation, enabling JavaScript execution in a higher-privileged user's authenticated session. The issue is fixed in versions 3.2.12, 3.3.10, and 3.4.2.

Argo CD ServerSideDiff in versions 3.2.0 through 3.2.12, 3.3.10, and 3.4.2 fails to properly sanitize Kubernetes Secret data, potentially exposing sensitive values including those in the kubectl.kubernetes.io/last-applied-configuration annotation. This allows sensitive data to appear in the UI or CLI diffs.