Argo CD's 18-Month-Old RCE Is a Warning Shot for GitOps Security

Somewhere in your cluster, a service is listening on an internal port with no authentication, waiting for anyone who can route a packet to it to execute arbitrary code. That’s the situation Argo CD users are in right now, and the maintainers have known about it since January 2025.

The French security firm Synacktiv published details of an unauthenticated remote code execution flaw in Argo CD’s repo-server component, a bug it says can lead to full Kubernetes cluster takeover. There is no patch, no CVE, and no advisory. According to Synacktiv, roughly eighteen months after the initial report to Argo CD’s maintainers, the flaw is still live in production installs — which is why the firm chose to publish now.

How an Unauthenticated gRPC Service Becomes a Cluster Takeover

The bug lives in repo-server, the Argo CD component that reads Git repositories and renders Kubernetes manifests. Its internal gRPC service has no authentication at all; anyone who can reach the port can send a crafted GenerateManifest request. Synacktiv demonstrated the attack against Argo CD v2.13.3 and reports no patched release exists.

The trick is elegant. Argo CD calls out to kustomize to render manifests, and kustomize accepts a --helm-command option that points to the helm binary. Synacktiv found that the unauthenticated gRPC call lets an attacker set that option to a script pulled from an attacker-controlled Git repository. When kustomize runs, it happily executes that script instead of helm. That collapses the distance between “an attacker has network reach to a pod” and “an attacker is running code in your GitOps controller” — arguably the most privileged workload in the entire cluster.

Imagine you’re running a mid-sized platform team with a single Argo CD instance managing dozens of tenant namespaces. One compromised sidecar in an unrelated tenant, and the attacker can pivot to controlling every deployment in every namespace Argo CD touches. The blast radius is the whole platform. My take: any tool that concentrates that much authority should treat every one of its internal ports as public until proven otherwise, and repo-server clearly wasn’t designed that way.

Why the Helm Chart Default Turns This Into a Real Threat

Here’s the part that makes this bug a live problem rather than a theoretical one. Argo CD does ship Kubernetes network policies that wall repo-server off from everything except its own components. But according to Synacktiv, the official Helm chart — the most common install path — leaves networkPolicy.create set to false by default. In that configuration, any pod in the cluster can reach repo-server.

Secure-by-default is not a nice-to-have anymore. The gap between the raw manifests (which include the network policies) and the Helm chart (which disables them) is exactly the kind of packaging drift that turns responsible defaults into shipped-off defaults. If you’re a team that installed Argo CD via helm install and never touched values.YAML, you likely have the vulnerable configuration right now. Run kubectl get networkpolicy -A and check that a policy exists for each Argo CD component, including repo-server and Redis. If nothing shows up, the internal ports are reachable from every workload in the cluster.

My prediction: within weeks of Synacktiv publishing its argo-cdown proof-of-concept on GitHub — which the firm says it’s holding back for now to give defenders time — we’ll see the first opportunistic scans hit exposed clusters. Anyone still on Helm chart defaults at that point is exposed.

The Redis Cache Attack That Refuses to Die

Running code on the repo-server would already be catastrophic, but Synacktiv chained it further. From the compromised repo-server, the researchers read the Redis password out of an environment variable, connected to Argo CD’s Redis cache, and poisoned the stored deployment data. On the next automatic sync, Argo CD dutifully deployed the attacker’s workload.

That step revives CVE-2024-31989, the 2024 flaw Cycode disclosed where Argo CD’s Redis had no password at all, letting any pod in the cluster poison the deployment cache directly. Argo CD’s fix was to add a Redis password — but as Synacktiv points out, the cache itself is still unsigned. Any attacker who can recover the password (from an environment variable, from a leaked pod spec, from a compromised repo-server) reopens the same attack surface.

Password-gating an integrity problem doesn’t fix the integrity problem. The right fix is signed cache entries so that even a database attacker can’t inject valid manifests. Until that ships, GitOps users have a soft trust boundary at the exact point where the platform decides what gets deployed. My take: this is going to keep happening — the same underlying weakness will resurface every time someone finds a new way to reach Redis.

A Pattern Argo CD Users Can No Longer Ignore

This isn’t Argo CD’s first exposure of its own internals. In September 2025, the project patched CVE-2025-55190, where an API token with basic read access could pull back a project’s Git repository credentials. In May 2026, CVE-2026-42880 let read-only users read plaintext Kubernetes secrets. Now we have an unauthenticated RCE with no patch in sight.

The pattern is clear: Argo CD concentrates cluster access and repository secrets in one place, and its internal surfaces keep handing those secrets out — to a low-privilege token in one bug, to an unauthenticated request in the next. If you run Argo CD, assume the pod hosting it is a crown-jewel target and treat the cluster network as hostile until a patch ships. That means enabling the shipped network policies, restricting egress from repo-server so it can only reach the Git hosts it needs, and treating Redis as a sensitive datastore rather than an ephemeral cache.

FAQ

Q: What is the Argo CD repo-server vulnerability? A: It’s an unauthenticated remote code execution flaw disclosed by Synacktiv in the repo-server component of Argo CD. An attacker who can reach the internal gRPC port can craft a GenerateManifest request that abuses kustomize’s --helm-command option to execute an attacker-supplied script, leading to full Kubernetes cluster takeover.

Q: Is there a CVE or patch for this Argo CD flaw? A: No. Synacktiv reported the issue to Argo CD’s maintainers in January 2025 and, per its disclosure, roughly eighteen months later there is still no patched release and no CVE assigned. The firm published details to warn users, and defenders currently have to rely on network isolation rather than a fix.

Q: How do I check if my Argo CD install is exposed? A: Run kubectl get networkpolicy -A and confirm there is a policy for each Argo CD component, specifically repo-server and Redis. If you installed Argo CD via its official Helm chart without customizing values, networkPolicy.create defaults to false, meaning any pod in the cluster can reach the vulnerable internal ports.

Key Takeaways

• Lock down Argo CD’s repo-server and Redis ports with the shipped Kubernetes network policies today, before Synacktiv’s argo-cdown tool goes public on GitHub.
• Audit any Helm-installed platform tooling in your clusters for secure defaults that were quietly turned off — the raw manifest and the chart don’t always agree.
• Expect more GitOps-controller CVEs in the next twelve months; concentrating deploy authority in one workload will keep drawing researcher attention.
• Push maintainers of security-critical CNCF projects to sign their internal caches, not just password-protect them, because CVE-2024-31989’s core weakness is still exploitable.
• If your organization uses Argo CD to manage regulated or multi-tenant workloads, escalate this internally now — an eighteen-month unpatched RCE in your deployment controller is a governance issue, not just an ops one.