---
schema: 1
kind: threat
title: "Argo CD repo-server unauthenticated RCE (no CVE, unpatched 18 months)"
headline: "Argo CD repo-server unauthenticated RCE (no CVE, unpatched 18 months)"
summary: "Synacktiv published a technical write-up of an unauthenticated remote-code-execution path in Argo CD — the dominant open-source GitOps continuous-delivery controller across EU/CH enterprise and public-sector Kubernetes estates — that it reported to the maintainers in January 2025 and that remains unpatched, with no …"
discovered_at: "2026-07-02T04:55:26Z"
event_date: 2026-07-01
run_id: 2026-07-02-6551f8c2
priority: notable
immediate_action: null
tags:
  - vulnerabilities
  - rce
  - pre-auth
  - no-patch
  - cloud
  - supply-chain
regions:
  - global
sectors:
  - technology
  - public-sector
entities:
  - "trend:argo-cd-repo-server-unauth-rce"
cves: []
sources:
  - url: "https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql"
    publisher: Synacktiv
    role: primary
  - url: "https://thehackernews.com/2026/07/unpatched-argo-cd-repo-server-flaw.html"
    publisher: The Hacker News
    role: corroborating
closed_sources: []
evidence: []
verification: multi-source
sourcing_note: null
confidence: high
update_of: null
references: []
deep_dive: true
deep_dive_category: cloud-saas
org_triage: null
watchlist_hit: false
actions:
  - "**Enforce Argo CD repo-server and Redis NetworkPolicies** — with no vendor patch for the unauthenticated repo-server RCE, set `networkPolicy.create=true` (the Helm chart ships it disabled), restrict repo-server gRPC ingress to the application-controller/server/repo-server components, and authenticate the Argo CD Redis instance. Treat any pod that can reach the repo-server gRPC port as cluster-admin-adjacent."
migrated_from: briefs/2026-07-02.md
---

Synacktiv published a technical write-up of an unauthenticated remote-code-execution path in Argo CD — the dominant open-source GitOps continuous-delivery controller across EU/CH enterprise and public-sector Kubernetes estates — that it reported to the maintainers in January 2025 and that remains unpatched, with no CVE assigned, as of publication ([Synacktiv, 2026-07-01](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)). The research is notable both for the finding and for the disclosure state: Synacktiv writes that "despite our ongoing efforts to establish communication and coordinate a fix, including numerous follow-ups via GitHub and email, the vulnerability remains unpatched," and the report has no CVE assigned ([The Hacker News, 2026-07-01](https://thehackernews.com/2026/07/unpatched-argo-cd-repo-server-flaw.html)).

**Vulnerable component and mechanics.** The flaw sits in Argo CD's `repo-server` component, specifically the internal gRPC service method `repository.RepoServerService/GenerateManifest`, which accepts a user-controlled `KustomizeOptions.BuildOptions` field with no authentication check. An actor able to reach the repo-server's gRPC port can inject an `--enable-helm --helm-command <path>` flag into the kustomize build invocation (`kustomize.go`), causing repo-server to execute an arbitrary attacker-supplied binary — sourced from an attacker-controlled Git repository — in place of the legitimate `helm` binary. The primitive is a classic argument-injection-to-arbitrary-execution: user input flows into a command-construction path that trusts the `helm-command` override.

**Why the port is reachable.** The repo-server gRPC port is nominally internal, but Argo CD's Helm chart ships its Kubernetes NetworkPolicies **disabled by default** — the manifests exist (`manifests/base/repo-server/argocd-repo-server-network-policy.yaml`) but require `networkPolicy.create=true` to take effect. In a flat/default cluster network, that leaves the port reachable from any pod. A single compromised or malicious workload elsewhere in the cluster is therefore a viable launch point — this is not solely an internet-exposure problem.

**Exploitation chain.**
1. **Initial access / execution** — reach the repo-server gRPC port and invoke `GenerateManifest` with a poisoned `KustomizeOptions.BuildOptions`, injecting `--helm-command` to run an attacker binary ([`T1190`](https://attack.mitre.org/techniques/T1190/), [`T1059`](https://attack.mitre.org/techniques/T1059/)).
2. **Credential access** — from code execution on repo-server, read the Redis password from the pod's environment variables ([`T1552.001`](https://attack.mitre.org/techniques/T1552/001/)).
3. **Impact / lateral movement** — connect to Argo CD's Redis cache (unauthenticated by default) and poison cached deployment manifests, so the next GitOps sync deploys an attacker-supplied workload cluster-wide — a full path from network-reachable-but-unauthenticated to cluster compromise.

**Detection concepts (no IOCs, no rule code).** Monitor repo-server pod logs for `GenerateManifest` gRPC calls carrying unexpected `KustomizeOptions` / `helm-command` build-option strings. Watch repo-server process trees for unexpected child binaries — anything other than the expected `helm`/`kustomize` executables — via container-runtime process-exec auditing. Alert on Redis connections to the Argo CD cache from sources other than the application-controller / server / repo-server components.

**Hardening / mitigation.** With no vendor patch available, the controlling mitigation is network isolation: enforce the repo-server and Redis NetworkPolicies shipped in the Argo CD manifests (deny-by-default ingress to the repo-server and redis pods, allowing only the application-controller, server and repo-server components). Helm-chart users must explicitly set `networkPolicy.create=true`, since the chart ships it disabled. Authenticate the Argo CD Redis instance. Until the maintainers ship a fix, treat any workload that can reach the repo-server gRPC port as effectively cluster-admin-adjacent and scope network access accordingly.