Argo CD, a widely used tool for deploying software to Kubernetes, has an unpatched flaw in its repo-server component that lets an unauthenticated attacker run code, provided they can reach the component’s internal network port.
Synacktiv, which found the bug, says it can lead to a full cluster takeover. There is no fix and no CVE. The firm says it reported the flaw to Argo CD’s maintainers in January 2025; roughly eighteen months later, it remains unpatched, so it published the details to warn users.
The bug sits in repo-server, the Argo CD component that reads Git repositories and builds Kubernetes manifests, the files that define what the cluster deploys.
Its internal gRPC service has no authentication; anyone who can reach it can send a crafted request to run a command. Synacktiv demonstrated the attack against Argo CD v2.13.3 and reports no patched release; it did not publish a full list of affected versions.
The technique 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.
Synacktiv found that 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.
Synacktiv found 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.
Running code on the repo-server is not the end of it. Synacktiv used that access to 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 deployed an attacker-supplied workload.
That step revives CVE-2024-31989, a 2024 flaw Cycode found 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, so stealing the password back reopens the same attack.
What to do
There is no patched version, so 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 -A. A 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.
Synacktiv built a tool, argo-cdown, that automates the full attack. It is holding the tool back for now to give defenders time to lock down their network policies, and says it will publish it on GitHub later so administrators can test their own deployments.
This is not Argo CD’s first exposure of its own internals. In September 2025, it patched CVE-2025-55190, where an API token with only basic read access could pull back a project’s Git repository credentials, a flaw that The Hacker News flagged at the time.
In May 2026, another bug, CVE-2026-42880, 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.
Until a patch ships, treating the cluster network as hostile is the only real defense.
