On July 1, 2026, security firm Synacktiv published a full attack chain against Argo CD's repo-server — the component that reads Git repositories and renders Kubernetes manifests. Its internal gRPC service ships with no authentication, so anyone who can reach it on the network can send a crafted GenerateManifest request that abuses Kustomize's --helm-command option to execute an arbitrary binary — unauthenticated remote code execution. From there, Synacktiv read the cluster's Redis password from an environment variable, poisoned Argo CD's Redis cache, and had Argo CD deploy an attacker-supplied workload on the next sync — a full cluster takeover. Critically, Synacktiv reported the chain to Argo CD's maintainers back in January 2025 and it remains unpatched roughly 18 months later. There is no CVE and no vendor fix; mitigation is entirely down to network isolation.

What the Vulnerability Is

Argo CD's repo-server turns repository files into Kubernetes manifests. It exposes an internal gRPC API that, by design, has no authentication — the security model assumes only trusted Argo CD components can reach it. In practice, if that gRPC port is reachable (misconfiguration, flat networking, missing network policies, or exposure inside a shared cluster), an attacker can call it directly.

The core of the exploit is the GenerateManifest gRPC endpoint combined with Kustomize, the standard tool Argo CD runs to build manifests. Kustomize supports a --helm-command option that specifies which helm binary to call. By supplying crafted Kustomize build options, the attacker points that "helm binary" at a command of their choosing, and repo-server executes it — arbitrary command execution with no credentials.

Synacktiv then escalated from code execution to control plane: they read the Redis password from an environment variable, connected to Argo CD's Redis cache, and poisoned the stored deployment data. On the next automatic sync, Argo CD faithfully deployed the attacker's manifest into the cluster. Because Argo CD holds broad permissions to apply resources, the attacker inherits the ability to run workloads clusterwide.

Why It Matters

  • Unauthenticated RCE. No token, no login — reachability of the gRPC service is enough.
  • GitOps is "tier zero" infrastructure. Argo CD typically has powerful, clusterwide deploy permissions. Compromising it is equivalent to compromising the control plane, not just one app.
  • Cache poisoning survives into production. Even a brief foothold lets an attacker plant a malicious workload that Argo CD re-deploys automatically on the next sync.
  • No patch exists. The issue was disclosed to maintainers in January 2025 and is still unpatched — you cannot "just update" your way out of this one today.
  • Shared and multi-tenant clusters are especially exposed. Any tenant or pod that can route to the repo-server or Redis ports becomes a takeover vector.

Am I Affected?

Consider yourself exposed if:

  • You run Argo CD for GitOps/continuous delivery into one or more Kubernetes clusters, and
  • The repo-server gRPC service (and/or the Argo CD Redis instance) is reachable by anything other than Argo CD's own trusted components — for example, other pods in the cluster, other tenants, or a loosely restricted network segment, and
  • You have not applied Kubernetes NetworkPolicies to lock those ports down (the Helm chart ships these policies disabled by default, so Helm-based installs are commonly wide open internally).

Because there is no fix, being on the latest Argo CD version does not by itself protect you. The exposure is about who can reach repo-server and Redis.

What to Do About It: Step-by-Step

Since no patch is available, remediation is network isolation and least privilege.

Step 1: Enable Kubernetes NetworkPolicies for Argo CD immediately

Argo CD ships policy manifests that restrict repo-server and Redis so only Argo CD's own components can talk to them. If you installed via Helm, these are off by default — turn them on:

# values.yaml (Argo CD Helm chart)
global:
  networkPolicy:
    create: true

Then upgrade the release and confirm policies exist:

kubectl get networkpolicy -n argocd

Step 2: Verify repo-server and Redis are not reachable from untrusted pods

From a throwaway pod in another namespace, confirm you cannot open the repo-server gRPC port (default 8081) or the Redis port (6379):

kubectl run netcheck --rm -it --image=busybox --restart=Never -- \
  sh -c "nc -zv argocd-repo-server.argocd.svc 8081; nc -zv argocd-redis.argocd.svc 6379"

Both should be refused/timed out once policies are in place.

Step 3: Never expose repo-server or Redis outside the cluster

Ensure there is no LoadBalancer, NodePort, or Ingress in front of these services. Only the Argo CD API/UI should ever be externally reachable, and that behind SSO.

Step 4: Set a strong Redis password and restrict it

Ensure Argo CD's Redis requires authentication, rotate the password, and confirm the credential isn't exposed to unrelated workloads. Treat any environment variable holding it as a secret.

Step 5: Constrain Argo CD's RBAC / cluster permissions

Apply least privilege so a repo-server compromise can't trivially deploy anywhere. Scope Argo CD to specific namespaces/clusters where feasible rather than granting broad cluster-admin-style rights.

Step 6: Enforce network segmentation for multi-tenant clusters

Default-deny egress/ingress between tenant namespaces so no tenant workload can route to the argocd namespace's internal services.

Step 7: Monitor for abuse

Watch repo-server logs for unexpected GenerateManifest activity and unusual Kustomize build options (especially --helm-command), and alert on out-of-band syncs or manifests that don't correspond to a Git commit.

Step 8: Track the upstream fix

Because there is no patch yet, subscribe to Argo CD security advisories and apply the official fix the moment it ships.

Quick-Win Checklist

  • Enabled Argo CD NetworkPolicies (global.networkPolicy.create=true for Helm installs).
  • Confirmed repo-server gRPC (8081) and Redis (6379) are unreachable from untrusted pods.
  • Verified no external LoadBalancer/NodePort/Ingress exposes repo-server or Redis.
  • Set and rotated a strong Redis password; treated it as a secret.
  • Tightened Argo CD RBAC to least privilege / scoped namespaces.
  • Applied default-deny network segmentation between tenants.
  • Added monitoring for anomalous GenerateManifest / Kustomize --helm-command usage and out-of-band syncs.
  • Subscribed to Argo CD advisories to apply the official patch when released.

Sources