"There is no fix and no CVE," Synacktiv warned after publishing technical details of an Argo CD repo-server flaw it says it reported in January 2025 but remained unpatched roughly eighteen months later.
The technical fault: unauthenticated gRPC in Argo CD's repo-server
Synacktiv found a flaw in Argo CD's repo-server component — the piece that reads Git repositories and builds Kubernetes manifests — where the internal gRPC service exposed by repo-server has no authentication. An unauthenticated request to the repo-server's GenerateManifest service can supply a crafted payload that sets kustomize's --helm-command option to a script pulled from an attacker-controlled Git repository. When Argo CD runs kustomize to generate manifests, kustomize executes that script instead of calling the helm binary. Synacktiv demonstrated the attack against Argo CD v2.13.3 and reports there is no patched release and no assigned CVE; Synacktiv did not publish a full list of affected versions.
Network configuration: policies are shipped but not enabled by default in the Helm chart
Argo CD ships Kubernetes network policies intended to wall the repo-server off from all non‑Argo CD components. However, Synacktiv found the common Helm chart leaves those policies off by default — the chart sets networkPolicy.create to false. In a chart install where networkPolicy.create remains false, the repo-server's internal ports are reachable from other pods in the cluster, meaning an attacker who compromises a single pod can reach the repo-server and trigger the unauthenticated request.
Synacktiv points administrators to a simple check: kubectl get networkpolicy -A. A healthy install, the firm says, shows one network policy per component, including for repo-server and for Redis; if those policies are missing, repo-server and Redis ports are reachable from the rest of the cluster.
From unauthenticated code execution to cache poisoning and cluster takeover
Synacktiv's demonstration did not stop at running code on the repo-server. Using that execution, the researchers read the cluster's Redis password from an environment variable, connected to Argo CD's Redis cache, and poisoned the stored deployment data. On the next automatic sync, Argo CD deployed an attacker-supplied workload — a complete escalation from a single unauthenticated request to code execution to deployment of malicious workloads.
The attack chain revives prior weaknesses. Cycode discovered CVE-2024-31989 in 2024 when Argo CD's Redis had no password and any pod in the cluster could poison the cache; Argo CD later added a Redis password, but the cache remains unsigned, Synacktiv notes, meaning stealing the password reopens the same attack vector. The pattern is reinforced by two other recent disclosures: CVE-2025-55190 (patched in September 2025), where an API token with only basic read access could return a project's Git repository credentials, and CVE-2026-42880 (May 2026), which allowed read-only users to read plaintext Kubernetes secrets. Synacktiv summarizes the trend: Argo CD concentrates cluster access and repository secrets, and its internal surfaces keep handing them out.
Tools and responsible disclosure: argo-cdown and the timeline
Synacktiv reported the repo-server flaw to Argo CD maintainers in January 2025. With no patch available roughly eighteen months later, Synacktiv published technical details to warn users. The researchers also built a tool, argo-cdown, that automates the full attack chain; they are withholding public release of that tool for now to give defenders time to enable protections, and say they will publish it on GitHub later so administrators can test their own deployments.
What this means for Argo CD administrators, Kubernetes security teams, and Helm deployers
- Argo CD administrators: enable the provided Kubernetes network policies so only Argo CD components can reach the repo-server and Redis ports; for Helm users this means setting networkPolicy.create to true in the chart. Use kubectl get networkpolicy -A to confirm policies are present — a healthy install shows one network policy per component, including repo-server and Redis.
- Kubernetes security teams: until a patched Argo CD release is available, treat the cluster network as hostile. If network policies are absent, a single compromised pod can reach internal Argo CD services and trigger the chain Synacktiv demonstrated.
- Helm deployers and procurement teams: be aware that the common Helm chart ships with networkPolicy.create set to false; require chart configuration that enables the shipped policies or apply equivalent network isolation at installation time.
Until a patch ships, the only practical defense Synacktiv offers is network isolation — and the researchers are deliberately delaying release of their test tool to give operators time to act. The facts are stark: an unauthenticated gRPC endpoint, a configurable kustomize hook, and default‑off network policies combine into an attack path that can end in full cluster takeover.
