No Patch, No CVE: Argo CD Repo-Server Flaw Opens Door to Kubernetes Cluster Takeover

Key points

• Argo CD's repo-server accepts unauthenticated gRPC calls on its internal port, and an attacker who can reach it can run arbitrary code.
• Synacktiv found the flaw and disclosed it to maintainers; no patch and no CVE have been issued.
• A compromised repo-server exposes the pod's service account token, and Argo CD service accounts carry enough privilege for full cluster takeover.
• Operators should isolate the repo-server with a NetworkPolicy immediately and audit its service account permissions while waiting for a vendor fix.

An unpatched flaw in Argo CD's repo-server component lets an unauthenticated attacker run arbitrary code on the host and, from there, seize the Kubernetes cluster it manages.

Synacktiv, an offensive-security firm, found and reported the bug to the Argo CD maintainers. No CVE has been assigned and no vendor patch exists.

Argo CD is a GitOps continuous-delivery tool that pushes application manifests into Kubernetes clusters. The repo-server is the internal component that clones Git repositories and renders those manifests. It's not meant to face end users, and it doesn't require authentication for the gRPC calls (a high-performance remote procedure call protocol) it accepts on its internal port. That design assumption is the root of the problem.

Any attacker who can reach the repo-server's port on the pod network can trigger the code-execution path. In a typical cluster that includes any workload sharing the network namespace, any pod that escapes its intended network policy, or anything on an adjacent segment where Argo CD's namespace is reachable. Once code runs inside the repo-server pod, the service account token mounted there becomes available. Argo CD service accounts are, by design, powerful. Cluster-admin escalation follows.

Synacktiv published without a fix in place. The project had not issued a security advisory at the time of writing, and no mitigation had shipped through the standard release channels at argo-cd.readthedocs.io.

There's no regulator with clean jurisdiction here. This is a software supply-chain risk, not a personal-data exposure. Operators running Argo CD in production regulated environments under PCI, HIPAA, or UK GDPR should treat an unauthenticated RCE in their deployment pipeline as a material control failure until it's remediated.

What should Argo CD operators do right now?

Restrict network access to the repo-server pod immediately. A NetworkPolicy should allow ingress only from the application-controller and API server pods within the argocd namespace; nothing else on the cluster should dial its gRPC port.

Audit the service account bound to the repo-server deployment and trim cluster-wide permissions where possible. The repo-server doesn't need broad cluster access to render manifests.

Review egress too. The repo-server pulls from Git and Helm registries, so lock those destinations down so a compromised pod can't exfiltrate freely.

Subscribe to the argo-cd GitHub security advisories feed and be ready to roll a patched image the moment one lands.

Should you worry if there's no CVE?

Yes. The absence of a CVE identifier doesn't mean the absence of a bug. It means the paperwork hasn't caught up. If your Argo CD instance is reachable from the public internet or from a shared tenancy network, assume you're in scope.

We covered an unauthenticated RCE in Splunk Enterprise that moved from disclosure to active exploitation within days, reported on 19 June 2026. The pattern is consistent: unpatched, no CVE, then suddenly weaponised. The Argo CD flaw sits at the same starting line.