CVE-2026-113709 in Argo CD
Summary
by MITRE • 10/20/2026
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. 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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
Argo CD serves as a declarative GitOps continuous delivery tool for Kubernetes environments, facilitating the automated deployment of applications based on source control repositories. A critical security vulnerability exists within versions ranging from 2.1.0 through specific patched releases including 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2. This flaw arises when an operator explicitly enables the --enable-helm flag for kustomize build operations. Under these conditions, a malicious actor can manipulate the helmGlobals.configHome parameter to direct Helm's configuration and data directories toward locations controlled by the attacker within the Git repository itself. This mechanism allows for arbitrary code execution with elevated privileges inside the Argo CD repo-server container, which is responsible for processing application manifests before they are synced to the cluster.
The technical core of this vulnerability lies in how Helm handles plugin loading when a custom config home directory is specified. By default, Helm loads downloader plugins from the .data/plugins subdirectory within its configuration path without requiring a separate installation step. When an attacker commits a Kustomization file that sets helmGlobals.configHome to a repository-controlled path containing a malicious plugin, and subsequently references this plugin via a specific protocol in a helmCharts repository URL, Argo CD executes the associated program inside the repo-server process. This execution occurs under the context of the repo-server user account, granting the attacker access to sensitive data such as repository credentials, service account tokens, and other environment variables accessible to that process. The vulnerability was introduced when Kustomize version 4.1.0 began passing the helmGlobals.configHome parameter directly through to Helm, thereby exposing this configuration vector in Argo CD deployments where kustomize builds are enabled alongside Helm support.
The operational impact of this flaw is severe due to the low barrier for exploitation and the high privilege level achieved by the attacker. There are two primary delivery paths for triggering this vulnerability. The first involves committing a malicious Kustomization file and plugin directly into a Git repository that an Argo CD Application monitors, relying on standard synchronization processes. The second path utilizes the POST /api/v1/applications/manifestsWithFiles endpoint or the argocd app diff --local --server-side-generate command to upload these files server-side. Crucially, this attack vector requires only Application get permission on an existing Application resource within Argo CD. It does not require Application update permissions, sync privileges, or write access to the Git repository itself. This means that even users with read-only access to application configurations can potentially compromise the entire deployment pipeline if they know which applications are being processed by a vulnerable repo-server instance.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code and CWE-78 OS Command Injection, as it allows an unprivileged user to execute arbitrary code within a privileged service account context. In terms of the MITRE ATT&CK framework for Kubernetes, this maps to T1505.003 Server Side Request Forgery via Plugin Loading and potentially T1620 Reflections through Execution, depending on how the plugin is utilized post-execution. The severity is further amplified by the fact that it bypasses standard authentication boundaries; a user who should only be able to view application status can effectively gain full control over the repo-server process, leading to potential cluster-wide compromise if credentials stored in the environment are exfiltrated or used for lateral movement.
Mitigation strategies must focus on immediate version upgrades and configuration hardening. Organizations running affected versions of Argo CD should upgrade immediately to patched releases such as 3.3.15, 3.4.10, 3.5.4, or later stable releases where this issue is resolved. For environments that cannot be upgraded instantly, operators can mitigate the risk by disabling the --enable-helm flag for kustomize build operations if Helm functionality within Kustomize builds is not strictly required. Additionally, implementing strict RBAC policies to limit Application get permissions to only those users who absolutely require it can reduce the attack surface. Monitoring repo-server logs for unusual plugin loading activities or unexpected process executions may also provide early detection indicators while longer-term remediation plans are executed. Ensuring that Helm plugins are installed via official channels rather than relying on dynamic loading from repository-controlled paths is a critical defense-in-depth measure to prevent similar exploitation vectors in future configurations.