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.
- Initial access / execution — reach the repo-server gRPC port and invoke
GenerateManifestwith a poisonedKustomizeOptions.BuildOptions, injecting--helm-commandto run an attacker binary (T1190,T1059). - Credential access — from code execution on repo-server, read the Redis password from the pod's environment variables (
T1552.001). - 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.
Defender actions
- Enforce Argo CD repo-server and Redis NetworkPolicies — with no vendor patch for the unauthenticated repo-server RCE, set
networkPolicy.create=true(the Helm chart ships it disabled), restrict repo-server gRPC ingress to the application-controller/server/repo-server components, and authenticate the Argo CD Redis instance. Treat any pod that can reach the repo-server gRPC port as cluster-admin-adjacent.
ATT&CK mapping
4 techniques mapped from the cited reporting · MITRE ATT&CK v19.1
Initial Access TA0001
T1190Exploit Public-Facing Application
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.
Execution TA0002
T1059Command and Scripting Interpreter
Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries. These interfaces and languages provide ways of interacting with computer systems and are a common feature across many different platforms. Most systems come with some built-in command-line interface and scripting capabilities, for example, macOS and Linux distributions include some flavor of Unix Shell while Windows installations include the Windows Command Shell and PowerShell.
Credential Access TA0006
T1552Unsecured Credentials
Adversaries may search compromised systems to find and obtain insecurely stored credentials. These credentials can be stored and/or misplaced in many locations on a system, including plaintext files (e.g. Shell History), operating system or application-specific repositories (e.g. Credentials in Registry), or other specialized files/artifacts (e.g. Private Keys).
T1552.001Unsecured Credentials: Credentials In Files
Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.