GPU VulnDB

Database/Container, Kubernetes & orchestration

Argo CD Helm chart: no network policies by default, so any pod on the cluster can reach repo-server

CVSS 8.6CVE-2026-62185Container, Kubernetes & orchestrationcurated

Impact

Installs from the Argo CD Helm chart before 10.0.0 ship without NetworkPolicies, so every pod in the cluster can open connections to repo-server and the other Argo CD APIs. repo-server renders manifests and holds repository credentials, and the advisory describes chaining that unrestricted reach into cluster compromise and remote code execution. On a multi-tenant GPU cluster this collapses the separation between a tenant's training or inference pod and the controller that decides what gets deployed to every node: a tenant who gets code execution in any pod - including through a model or notebook they submitted - can attack the deployment path for the whole fleet. Nothing about the attack requires Argo CD credentials; it requires only being a pod on the same cluster network.

Who can reach it

Any workload running as a pod on the cluster, including an untrusted tenant pod, reaching the Argo CD service network. No Argo CD authentication needed to reach the exposed APIs.

What to do

Upgrade the Argo CD Helm chart to 10.0.0 or later, which installs the network policies, or add equivalent NetworkPolicies yourself restricting ingress to argocd-repo-server and the Argo CD APIs to the argocd namespace. Either way this is a redeploy of the Argo CD release and a restart of its pods - no GPU node drain, no reboot. Requires a CNI that enforces NetworkPolicy; on clusters where it is not enforced, segment at the service-mesh or firewall layer instead.

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.