CVE-2026-113672

In Argo CD from 2.1.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, when an operator has enabled --enable-helm for kustomize build, helmGlobals.configHome can point Helm's config and data directories at a repository-controlled location. Helm automatically loads a downloader plugin from <configHome>/.data/plugins without a separate plugin-install step and executes its program inside argocd-repo-server when a helmCharts repository URL uses the plugin's protocol. The command runs as the repo-server user and can read repository credentials and other process-accessible data. An attacker can commit the Kustomization and plugin to a Git repository that an Application builds or upload the 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. Both delivery paths require prior operator enablement of --enable-helm; deployments that do not enable it are not affected. Kustomize 4.1.0 first passed helmGlobals.configHome through to Helm. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2.

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.

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.