18 months without a fix: How an Argo CD vulnerability exposed the entire Kubernetes cluster

6 min read

For 18 months, a vulnerability has lurked in the Argo CD repo server-one that still lacks a patch or even a CVE number. The internal gRPC service performs no identity checks. Anyone reaching it inside the cluster can execute commands, poison the Redis cache, and push their own workloads on the next sync. A single compromised pod is all it takes.

Key Takeaways

• No patch, no CVE: Synacktiv reported the flaw to Argo CD maintainers in January 2025 and published full details on 1 July 2026. A fix remains absent.
• The repo server is the entry point: Its gRPC service runs without authentication. By crafting a Kustomize option, an attacker executes unauthenticated code.
• Defense lives in the network: Kubernetes NetworkPolicies isolate the repo server and Redis. Argo CD ships the rules, but Helm installations disable them by default.

Related:Kubernetes Governance in Multi-Cloud Environments  /  What the Cilium Upgrade Can Break in Your Cluster

What Synacktiv Found Inside the Repo Server

The repo server is the component that does the heavy lifting for Argo CD. It reads Git repositories and turns them into ready-to-deploy Kubernetes manifests. To let the other Argo pieces talk to it, it exposes an internal gRPC endpoint. That endpoint never asks for an identity. Any process that reaches it over the network can send it requests.

This is where the Synacktiv researchers strike. Argo CD invokes the standard tool Kustomize to build manifests. Kustomize has an option that lets you set the path to the Helm binary. By crafting a request, an attacker points that option to any command. The result is unauthenticated command execution smack in the middle of the deployment chain.

The attack doesn’t end at the repo server. The researchers extracted the Redis password from an environment variable, connected to the Argo CD cache, and tampered with the stored deployment data. On the next automatic sync, Argo CD obediently rolled out the injected workload. What started as a read-only peek at a helper service becomes full control of the entire cluster.

Why a Deployment Tool Holds the Key to Your Cluster

GitOps has all the right arguments on its side. The desired state lives in Git, a controller continuously reconciles it with the live cluster. Traceable, versioned, free of manual kubectl tinkering. The price of this convenience rarely appears on the architecture diagram: whoever controls the deployment path controls everything that runs at the end of that path.

Argo CD decides which containers go into production. It holds the credentials it needs for reconciliation. By definition, it has write access to the cluster. An attacker who takes over this machinery no longer needs to crack individual applications. They simply write themselves into the desired state and let the controller do the dirty work.

That’s why experts argue, as in this case, that GitOps infrastructure deserves Tier-0 treatment-on the same protection level as the identity system or the certificate authority. Not as a second-tier deployment tool, but for what it truly is: the control center of production.

Five Steps to Lock Down the Repo-Server Right Now

Waiting for a vendor patch isn’t an option because there isn’t one. The good news: the attack needs network access to the repo-server. That’s exactly where it can be stopped.

1. Enable NetworkPolicies. Argo CD ships with ready-made rules that only allow its own components to reach the repo-server and Redis. In Helm installations these rules are disabled. Turning them on is the single most effective step.
2. Segment repo-server and Redis. Both ports belong in their own network segment. No other pod in the cluster has any business there.
3. Audit exposure. Check which workloads can currently reach the gRPC port. In standard Helm setups that often means the entire cluster.
4. Question chart defaults. The case follows a pattern: secure options exist but are switched off. This applies beyond Argo CD to many Helm charts.
5. Watch sync behavior. Unexpected deployments or changes to the desired state are the warning signal. Manipulating the Redis cache leaves traces in the reconciliation log.

Standard installation vs. hardened setup

The difference between vulnerable and secure doesn’t lie in a new component, but in the default settings you need to know and configure.

What admins should take away from this incident

The real lesson isn’t about Argo CD itself, but about the assumption behind it. Internal services were long treated as trustworthy simply because they sat behind the cluster boundary. An unauthenticated gRPC endpoint is the natural result of that assumption-and it no longer holds the moment a single pod on the same network is compromised.

If you run GitOps, treat the control plane like the door to the server room: segmented, monitored, with explicitly defined rules instead of inherited defaults. The patch for this gap hasn’t arrived yet. But the control over your own network is already in your hands-if you choose to take it.

Frequently Asked Questions

Source of title image: AI-generated (July 2026)

Image source: AI-generated (July 2026)