Argo CD has a serious problem. A security researcher found an unpatched bug in the repo-server component that lets unauthenticated attackers run code — as long as they can reach the right internal network port.
Synacktiv discovered the flaw. They say it can lead to a full Kubernetes cluster takeover. There’s no fix available, and no CVE has been assigned. The firm reported it to Argo CD’s maintainers in January 2025. Eighteen months later, nothing’s been patched, so they went public.
The bug lives in the repo-server’s internal gRPC service, which has no authentication. Anyone who can reach it can send a crafted request that runs a command. Synacktiv demonstrated the attack against Argo CD v2.13.3.
Here’s how it works. The repo-server uses kustomize to turn repository files into Kubernetes manifests. Kustomize has a --helm-command option that points to the helm binary. An unauthenticated request to the GenerateManifest service can set that option to a malicious script from an attacker-controlled Git repo. When kustomize runs, it executes the script.
But there’s a catch. Argo CD ships Kubernetes network policies that wall off the repo-server. The problem? The Helm chart leaves those policies disabled by default, with networkPolicy.create set to false. In that setup, compromising a single pod gives an attacker access to the repo-server.
From there, Synacktiv read the Redis password from environment variables, connected to Argo CD’s cache, and poisoned deployment data. On the next sync, Argo CD deployed attacker-controlled workloads. This revives an old 2024 flaw (CVE-2024-31989) where Redis had no password.
Until a patch ships, network isolation is the only defense. Enable the built-in network policies. Check with kubectl get networkpolicy -A. If those policies are missing, your repo-server and Redis ports are exposed.
Synacktiv built an automated attack tool called argo-cdown but is holding it back to give defenders time to lock things down.
