GPU VulnDB

Database/Container, Kubernetes & orchestration

Argo CD repo-server: repository-controlled Helm configHome auto-loads a downloader plugin and executes it

CVSS 9.9CVE-2026-113709Container, Kubernetes & orchestrationcurated

Impact

When an operator has enabled --enable-helm for kustomize build, helmGlobals.configHome can point Helm's config and data directories at a repository-controlled path. Helm then loads a downloader plugin from <configHome>/.data/plugins with no separate install step and executes its program inside argocd-repo-server as soon as 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 - the GitOps controller that defines the whole GPU fleet's desired state. Deployments that never enabled --enable-helm are not affected, which makes this one worth checking your repo-server flags before scheduling anything.

Who can reach it

An authenticated Argo CD user with only Application get permission on an existing Application, via POST /api/v1/applications/manifestsWithFiles (also reachable through argocd app diff --local --server-side-generate); or anyone with git push access to a repository an Application builds. Both paths additionally require that the operator has already enabled --enable-helm.

What to do

Upgrade Argo CD to 3.3.15, 3.4.10, 3.5.4 or 3.6.0-rc2 and restart argocd-repo-server. As an interim mitigation, disable --enable-helm for kustomize build if your Applications do not need Kustomize-rendered Helm charts; that alone removes both delivery paths. Rolling the repo-server does not disturb running GPU workloads.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.