Unpatched Argo CD Repo-Server Bug Could Expose Kubernetes Clusters to Takeover

Security researchers say an unpatched flaw in Argo CD’s repo-server component could allow an attacker to execute code and potentially gain control of a Kubernetes cluster, as long as they can reach the service on the internal network.

The issue was identified by Synacktiv, which said it reported the problem to Argo CD maintainers in January 2025. After waiting roughly 18 months without a fix or CVE assignment, the company disclosed the findings to alert users. According to its analysis, the weakness affects the repo-server’s gRPC interface, which does not require authentication.

How the attack works

Argo CD uses repo-server to fetch Git repositories and generate Kubernetes manifests. Synacktiv found that an unauthenticated request to the GenerateManifest service can be crafted so that kustomize is instructed to invoke a script from an attacker-controlled repository instead of the expected Helm binary. When the service processes the request, that script is executed.

The exposure depends heavily on network reachability. Argo CD offers Kubernetes network policies intended to isolate repo-server and Redis from the rest of the cluster, but Synacktiv notes that the common Helm-based installation leaves those protections disabled by default. In that configuration, a compromised pod elsewhere in the cluster may be able to contact repo-server and trigger the flaw.

Why the impact is serious

Gaining code execution on repo-server can be enough to move further into the environment. Synacktiv showed that an attacker could read the Redis password from the component’s environment, connect to Argo CD’s Redis cache, and alter stored deployment data. On the next sync cycle, Argo CD would deploy attacker-supplied content.

The researchers said this also reopens the risk pattern behind CVE-2024-31989, a previous issue in which weak Redis protections let a pod poison deployment state. Although Argo CD later added a Redis password, the cache data itself is not cryptographically signed, so secrets exposed from the running service can still be abused.

What administrators should do

• Enable Kubernetes network policies for Argo CD components, especially repo-server and Redis.
• Verify protections with kubectl get networkpolicy -A.
• Confirm that the expected policies are present in every namespace used by Argo CD.

Synacktiv said it has built an attack tool called argo-cdown, but is delaying publication to give defenders time to lock down their deployments. Until a patch is available, the company recommends treating the cluster network as untrusted and restricting access as tightly as possible.