CVE-2026-62185: Argo CD Helm Chart RCE Vulnerability

CVE-2026-62185 Overview

CVE-2026-62185 affects the Argo CD Helm Chart in versions prior to 10.0.0. The chart fails to install Kubernetes network policies by default. As a result, any pod running on the cluster can reach the repo-server and other internal Argo APIs without network-level restriction.

Attackers who gain a foothold in a low-privileged pod can chain this unrestricted access with other weaknesses to achieve cluster compromise and remote code execution. The weakness is classified under [CWE-1188] (Insecure Default Initialization of Resource).

Critical Impact
Any pod on the cluster can reach Argo CD internal APIs, enabling lateral movement, credential theft, and remote code execution within the Argo CD control plane.

Affected Products

Argo CD Helm Chart versions prior to 10.0.0
Kubernetes deployments installing Argo CD via the affected chart
Clusters where no supplementary NetworkPolicy resources restrict access to argocd-repo-server and related services

Discovery Timeline

2026-07-13 - CVE-2026-62185 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-62185

Vulnerability Analysis

Argo CD is a declarative GitOps continuous delivery controller for Kubernetes. Its architecture separates concerns across multiple internal services, including argocd-server, argocd-repo-server, argocd-application-controller, and argocd-redis. These components communicate over cluster-internal gRPC and HTTP endpoints.

The official Argo CD Helm Chart is the primary installation method for production deployments. In versions before 10.0.0, the chart does not ship or enable Kubernetes NetworkPolicy resources by default. Kubernetes clusters treat all pod-to-pod traffic as allowed unless a NetworkPolicy explicitly restricts it.

The result is that internal Argo services are reachable from any pod in the cluster, not only from other Argo CD components. An attacker who compromises an unrelated workload can directly query the repo-server API and interact with additional Argo endpoints intended to be internal.

Root Cause

The root cause is an insecure default configuration in the Helm chart. Security-relevant NetworkPolicy manifests were either absent or disabled by default, leaving segmentation as an opt-in choice rather than a baseline control. This violates least-privilege network design for a component that handles Git credentials, cluster manifests, and deployment secrets.

Attack Vector

Exploitation requires adjacent network access, meaning the attacker must have code execution inside a pod on the same Kubernetes cluster. From that pod, the attacker sends requests directly to Argo CD internal services over the cluster network.

The repo-server renders manifests from Git repositories and holds repository credentials. Combined attacks against exposed internal APIs can extract these secrets, manipulate rendered manifests, or trigger unsafe template execution paths, leading to remote code execution within the Argo CD control plane and, by extension, the workloads it manages.

See the GitHub Security Advisory GHSA-47m3-95c7-g2g8 and the VulnCheck Advisory for additional technical context.

Detection Methods for CVE-2026-62185

Indicators of Compromise

Unexpected TCP connections from non-Argo pods to argocd-repo-server on port 8081 or to argocd-server gRPC/HTTPS ports
Anomalous API calls to Argo CD internal endpoints originating from workloads outside the argocd namespace
New or modified Argo CD Application resources that reference unfamiliar Git repositories or Helm charts

Detection Strategies

Audit the installed Argo CD Helm chart version and confirm whether NetworkPolicy resources exist in the argocd namespace using kubectl get networkpolicy -n argocd
Review Kubernetes audit logs for API calls modifying Argo CD custom resources from unexpected service accounts
Correlate egress connections from application pods against the cluster IP ranges of Argo CD services

Monitoring Recommendations

Enable Kubernetes audit logging at the Metadata level or higher for the argoproj.io API group
Deploy a CNI-integrated flow logger, such as Cilium Hubble or Calico flow logs, to record pod-to-pod traffic to the argocd namespace
Alert on any pod outside argocd establishing connections to argocd-repo-server or argocd-redis

How to Mitigate CVE-2026-62185

Immediate Actions Required

Upgrade the Argo CD Helm Chart to version 10.0.0 or later, which ships network policies enabled by default
Apply Kubernetes NetworkPolicy resources restricting ingress to Argo CD components to only the required pods and namespaces
Rotate any Git repository credentials, SSH keys, and cluster secrets stored or accessible through argocd-repo-server

Patch Information

The fix is delivered in Argo CD Helm Chart version 10.0.0. Upgrade using helm repo update followed by helm upgrade argocd argo/argo-cd --version 10.0.0 against the existing release. Review the chart values for the network policy toggle to confirm it remains enabled after upgrade. Refer to the GitHub Security Advisory for release notes and value changes.

Workarounds

Manually author and apply NetworkPolicy manifests that deny all ingress to the argocd namespace and allow only required intra-namespace traffic
Enforce a cluster-wide default-deny policy at the CNI layer so new namespaces inherit segmentation
Restrict which service accounts and users can create pods in namespaces adjacent to Argo CD until upgrade is complete

bash

# Example default-deny plus targeted allow for the argocd namespace
kubectl apply -n argocd -f - <<'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-argocd-internal
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/part-of: argocd
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/part-of: argocd
EOF