Argo CD is the backbone of GitOps for countless Kubernetes deployments. It reads Git repositories, builds manifests, and keeps clusters in sync. It also has an unpatched flaw in its repo-server component that lets an unauthenticated attacker run code.
The flaw was discovered by Synacktiv. It can lead to a full cluster takeover. There is no fix. There is no CVE. The firm reported the flaw to Argo CD's maintainers in January 2025. Roughly eighteen months later, it remains unpatched. Synacktiv published the details to warn users.
The bug sits in repo-server, the component that reads Git repositories and builds Kubernetes manifests. Its internal gRPC service has no authentication. Anyone who can reach it can send a crafted request to run a command.
How the Attack Works
The Argo CD repo-server unauthenticated flaw abuses kustomize, a standard tool Argo CD runs to turn repository files into manifests. Kustomize has a --helm-command option that points to the helm binary it should call.
An unauthenticated request to the repo-server's GenerateManifest service can set that option to a script instead pulled from an attacker-controlled Git repository. When kustomize runs, it executes the script rather than helm.
But "internal" does not mean isolated by default. Argo CD ships Kubernetes network policies that wall the repo-server off from everything except its own components. The Helm chart a common way to install Argo CD leaves those policies off by default, with networkPolicy.create set to false.
In that setup, an attacker who compromises a single pod in the cluster can reach the repo-server and trigger the bug.
The Redis Connection: A 2024 Flaw Returns
Running code on the repo-server is not the end of it. The attacker can read the cluster's Redis password from an environment variable, connect to Argo CD's Redis cache, and poison the stored deployment data. On the next automatic sync, Argo CD deploys an attacker-supplied workload.
That step revives a 2024 flaw where Argo CD's Redis had no password, letting any pod in the cluster poison the deployment cache. Argo CD fixed that by adding a Redis password, but the cache itself is still not signed. Stealing the password back reopens the same attack.
A Pattern, Not a One-Off
The Argo CD repo-server unauthenticated flaw is not the first time Argo CD's internal surfaces have been exposed. In September 2025, a vulnerability allowed an API token with only basic read access to pull back a project's Git repository credentials. In May 2026, another flaw allowed read-only users to read plaintext Kubernetes secrets.
The pattern is hard to miss: Argo CD concentrates cluster access and repository secrets, and its internal surfaces keep handing them out to an unauthenticated request in one bug and a low-privilege token in the next.
What to Do
There is no patched version of Argo CD for the Argo CD repo-server unauthenticated flaw. The defense is network isolation.
Turn on Kubernetes network policies so only Argo CD's own components can reach the repo-server and Redis ports. Argo CD provides the policy files; Helm users have to enable them because the chart leaves them off.
Check what is active with:
kubectl get networkpolicy -AA healthy install shows one network policy per component, including the repo-server and Redis. If those policies are missing, the repo-server and Redis ports are reachable from the rest of the cluster.
The Bottom Line
The Argo CD repo-server unauthenticated flaw has no patch and no CVE. It has been unpatched for eighteen months. The only defense is network isolation. If your Argo CD deployment uses the default Helm chart settings, your repo-server and Redis are reachable from any compromised pod in the cluster.
Check your network policies. Enable them. Isolate the repo-server. Until a patch ships, treating the cluster network as hostile is the only real defense.
FAQ Section
What is the Argo CD repo-server flaw?
It is an unauthenticated remote code execution vulnerability in Argo CD's repo-server component. It allows an attacker who can reach the repo-server's internal port to execute arbitrary commands.
Does there exist a patch?
There is no patch for the bug that was disclosed in January 2025. There is no CVE for it.
How does the attack happen?
The attacker misuses kustomize’s --helm-command parameter and runs a malicious script in place of helm. This script is obtained by the attacker from their own Git repository.
How can an attacker reach the repo-server?
The Helm chart leaves Kubernetes network policies disabled by default. An attacker who compromises any pod in the cluster can reach the repo-server.
What is the Redis connection?
The attacker can steal the Redis password from an environment variable, poison the deployment cache, and cause Argo CD to deploy attacker-controlled workloads on the next sync.
What should I do?
Implement Kubernetes network policies that would restrict the repo-server and Redis from any traffic besides that which comes from Argo CD components only.
