Argo CD, the popular GitOps tool, has an unpatched weakness in its repo-server component that can let a determined attacker run code — if they can talk to the right internal port. Researchers at Synacktiv found the issue, reported it in January 2025, and after about eighteen months with no fix and no CVE, decided to publish the details so admins could protect themselves.

The bug, explained without the scary jargon

Here’s the nutshell version: the repo-server exposes an unauthenticated gRPC endpoint. That means anyone who can reach it can send a crafted GenerateManifest request. The request can abuse kustomize’s option that tells it what helm binary to run (the –helm-command flag). If you point that option at a script pulled from an attacker-controlled Git repo, kustomize will happily execute the script instead of running a legit helm program.

The problem chains together like unfortunate dominos: reaching the repo-server lets you run code there → that code can read environment variables (like the Redis password) → you can connect to Argo CD’s Redis and tamper with the cached deployment manifests → on the next automatic sync, Argo CD deploys whatever you injected. The researchers demonstrated the attack against Argo CD v2.13.3 and did not see a patched release.

Two important things to highlight: the exposed service is an internal gRPC endpoint, and the whole scenario becomes dangerous when cluster network restrictions are not enforced. The official Argo CD distribution includes network policy manifests that lock repo-server off from the rest of the cluster, but common Helm chart defaults leave those policies disabled, which opens the door.

What to do right now (yes, this is urgent)

There’s no official patched version to install yet, so your best defense is to treat the cluster like a suspicious cocktail party and shut the doors.

  • Enable Kubernetes network policies so only Argo CD’s own components can reach the repo-server and Redis ports. Look for one network policy per component in a healthy install.
  • If you used the Helm chart, set networkPolicy.create to true (or apply the provided network policy manifests). By default many chart installs leave policies off.
  • Check your cluster now with: kubectl get networkpolicy -A — if repo-server and Redis policies are missing, those ports may be reachable from any compromised pod.
  • Rotate secrets that Argo CD uses (Redis password, service accounts, tokens) and review who can list pods or exec into them. If an attacker already had a foothold, assume credentials might be compromised.
  • Audit recent Argo CD activity and Kubernetes events for unexpected GenerateManifest requests, manifest changes, or new deployments originating from Argo CD syncs.
  • Isolate and investigate any suspicious pods in the cluster — an attacker who can reach repo-server often got there by compromising another pod first.

Synacktiv also built an automated proof-of-concept tool (called argo-cdown) but delayed public release to give admins time to lock things down. That’s a reminder this is practical, not theoretical.

Historically, Argo CD has had a few incidents where internal surfaces leaked sensitive material or allowed low-privilege access to escalate. Until a proper patch lands, assume your cluster network is hostile and minimize who and what can talk to Argo CD internals. And yes, making those network policies actually exist is the first, simplest fix.