Security researchers at Synacktiv have published details of a vulnerability in Argo CD, one of the most widely used GitOps tools for Kubernetes, that illustrates why the infrastructure responsible for deploying your applications deserves more protection than most teams give it.
The flaw targets the repo-server component, specifically its GenerateManifest gRPC endpoint. By exploiting the way Argo CD processes Kustomize manifest generation requests, an attacker who has already gained access to a pod inside the cluster can escalate to full control of application deployments — potentially injecting malicious code into every service that Argo CD manages.
The vulnerability is not a remote code execution exploit in the traditional sense. It requires the attacker to already have a foothold in the cluster. But the researchers argue that this is precisely why GitOps infrastructure needs to be treated as “tier zero” — the most critical layer — rather than as just another internal service.
How the Exploit Works
The attack chain starts with the GenerateManifest gRPC endpoint on Argo CD’s repo-server. This endpoint is unauthenticated by design; it’s meant to be called only from within the cluster by other Argo CD components. The problem is that an attacker with access to any pod inside the cluster can reach it.
Once connected, the attacker can supply custom Kustomize options in a manifest generation request. Synacktiv demonstrated that by abusing Kustomize’s Helm-related build options, it’s possible to inject and execute arbitrary commands. From there, the researchers escalated in two directions.
First, they extracted the Redis password from the repo-server’s environment variables. With Redis credentials in hand, they accessed Argo CD’s Redis database, which stores cached deployment manifests. By modifying the cached data, they could plant a malicious manifest that Argo CD would pick up and deploy automatically — if Auto Sync was enabled — the next time it reconciled cluster state.
If Auto Sync wasn’t enabled, the attack still works, but it requires a user or administrator to manually trigger a sync after the cache has been tampered with. Either way, the result is the same: attacker-controlled resources deployed into the cluster with whatever permissions Argo CD itself holds.
The exploit requires access to two network ports: the repo-server’s gRPC port and the Redis database port. Neither should be exposed to users or external traffic in a properly configured cluster. But Synacktiv found that the Kubernetes network policies designed to enforce this isolation are not enabled by default when deploying Argo CD via its official Helm chart. In those default deployments, compromising a single pod anywhere in the cluster can give an attacker the internal network access needed to reach both ports and execute the full attack.
Why This Matters More Than a Typical CVE
Argo CD operates with significant privileges inside a Kubernetes cluster. It has write access to deploy and modify resources. It holds credentials for private Git repositories. And in many organizations, it sits at the intersection of development pipelines and production infrastructure — a single point of control for what runs and where.
Compromising Argo CD, even through a multi-step attack like this one, means compromising the deployment pipeline itself. An attacker who controls Argo CD doesn’t need to find vulnerabilities in individual applications. They can inject their code directly into the manifests that define how those applications are built and deployed.
Synacktiv’s report frames this in the language of “tier zero” infrastructure. In security architecture, tier zero typically refers to the identity and access management systems that control who can access what. The argument here is that GitOps tools like Argo CD have evolved to occupy a similar position: they control what runs, and anything that controls what runs needs the same level of hardening as the systems that control who accesses.
What You Should Do
The Argo CD project has released patches for the vulnerability. If you’re running Argo CD in production, updating to the latest version is the first step.
Beyond the patch, Synacktiv recommends several configuration changes that close the attack surface even if an attacker compromises a pod in your cluster:
Enable network policies. The Argo CD Helm chart includes Kubernetes network policies that restrict access to the repo-server gRPC port and the Redis port. They are not enabled by default. Set networkPolicy.enabled: true in your Helm values.
Restrict repo-server access. The repo-server’s gRPC endpoint does not need to be reachable from every pod in the cluster. Use network policies to limit access to only the Argo CD application controller and API server.
Audit your Redis configuration. If you’re running Redis separately from the Argo CD Helm deployment, verify that the Redis instance is not exposed to pods that don’t need it. Use a strong password and rotate it regularly.
Treat Argo CD namespace as production. Apply the same pod security standards, network policies, and access controls to the Argo CD namespace that you apply to your production workloads. If a developer’s test pod can reach the repo-server, your GitOps pipeline is only as secure as the least-trusted pod in the cluster.
Monitor for anomalies. Watch for unexpected access to the repo-server gRPC port (typically on port 8081) and for modifications to Redis cache entries. Argo CD’s own logs can provide early warning if an attacker attempts to exploit the GenerateManifest endpoint.
Consider running repo-server as a separate workload. For clusters where security is paramount, run the repo-server component in a dedicated namespace or even a separate cluster with strict ingress and egress controls. This compartmentalization means that even if an attacker compromises a pod in your main application namespace, they cannot reach the GitOps pipeline’s critical components.
Audit the permissions Argo CD holds. Many teams deploy Argo CD with cluster-admin level access because it simplifies configuration. Audit your Argo CD ServiceAccount and RBAC configuration. Does it need write access to every namespace? Can you scope it to only the namespaces it manages? The principle of least privilege applies to your deployment tools just as much as to your applications.
The broader takeaway isn’t about Argo CD specifically. It’s about the architectural assumption that internal services are safe by default. GitOps tools have quietly become as critical as the clusters they manage, and the industry’s security practices need to catch up. When a single component controls what code runs across your entire infrastructure, a defense-in-depth approach stops being optional — the default configuration, as Synacktiv’s research shows, leaves gaps that an attacker with a single pod compromise can exploit.
