Argo CD repo-server unauthenticated RCE (no CVE, unpatched 18 months)

Synacktiv published a technical write-up of an unauthenticated remote-code-execution path in Argo CD — the dominant open-source GitOps continuous-delivery controller across EU/CH enterprise and public-sector Kubernetes estates — that it reported to the maintainers in January 2025 and that remains unpatched, with no CVE assigned, as of publication (Synacktiv, 2026-07-01). The research is notable both for the finding and for the disclosure state: Synacktiv writes that "despite our ongoing efforts to establish communication and coordinate a fix, including numerous follow-ups via GitHub and email, the vulnerability remains unpatched," and the report has no CVE assigned (The Hacker News, 2026-07-01).

Vulnerable component and mechanics. The flaw sits in Argo CD's repo-server component, specifically the internal gRPC service method repository.RepoServerService/GenerateManifest, which accepts a user-controlled KustomizeOptions.BuildOptions field with no authentication check. An actor able to reach the repo-server's gRPC port can inject an --enable-helm --helm-command <path> flag into the kustomize build invocation (kustomize.go), causing repo-server to execute an arbitrary attacker-supplied binary — sourced from an attacker-controlled Git repository — in place of the legitimate helm binary. The primitive is a classic argument-injection-to-arbitrary-execution: user input flows into a command-construction path that trusts the helm-command override.

Why the port is reachable. The repo-server gRPC port is nominally internal, but Argo CD's Helm chart ships its Kubernetes NetworkPolicies disabled by default — the manifests exist (manifests/base/repo-server/argocd-repo-server-network-policy.yaml) but require networkPolicy.create=true to take effect. In a flat/default cluster network, that leaves the port reachable from any pod. A single compromised or malicious workload elsewhere in the cluster is therefore a viable launch point — this is not solely an internet-exposure problem.

Exploitation chain.

1. Initial access / execution — reach the repo-server gRPC port and invoke GenerateManifest with a poisoned KustomizeOptions.BuildOptions, injecting --helm-command to run an attacker binary (T1190, T1059).
2. Credential access — from code execution on repo-server, read the Redis password from the pod's environment variables (T1552.001).
3. Impact / lateral movement — connect to Argo CD's Redis cache (unauthenticated by default) and poison cached deployment manifests, so the next GitOps sync deploys an attacker-supplied workload cluster-wide — a full path from network-reachable-but-unauthenticated to cluster compromise.

Detection concepts (no IOCs, no rule code). Monitor repo-server pod logs for GenerateManifest gRPC calls carrying unexpected KustomizeOptions / helm-command build-option strings. Watch repo-server process trees for unexpected child binaries — anything other than the expected helm/kustomize executables — via container-runtime process-exec auditing. Alert on Redis connections to the Argo CD cache from sources other than the application-controller / server / repo-server components.

Hardening / mitigation. With no vendor patch available, the controlling mitigation is network isolation: enforce the repo-server and Redis NetworkPolicies shipped in the Argo CD manifests (deny-by-default ingress to the repo-server and redis pods, allowing only the application-controller, server and repo-server components). Helm-chart users must explicitly set networkPolicy.create=true, since the chart ships it disabled. Authenticate the Argo CD Redis instance. Until the maintainers ship a fix, treat any workload that can reach the repo-server gRPC port as effectively cluster-admin-adjacent and scope network access accordingly.