SURIQ
Argo CD, the tool a large share of teams use to push software into Kubernetes, has an unauthenticated way to run code on its own servers, and there is no patch to install. Synacktiv disclosed the flaw on July 1, 2026, eighteen months after reporting it privately, and the maintainers have shipped no fix and not even a CVE. That reframes the job in front of you. This is not a version bump you schedule for the next maintenance window. It is a network boundary you have to build, because the component at the center of it was never designed to check who is calling.
A control plane that trusts the network, not the caller
The repo-server is the Argo CD component that reads your Git repositories and renders the Kubernetes manifests Argo CD applies. Its internal gRPC service has no authentication. It assumes that nothing but Argo CD's own machinery is meant to talk to it, and Synacktiv found that assumption is the entire security model. Anyone who can open a connection to it can ask it to render a manifest, and that request path is where the trouble starts.
The chain, which Synacktiv nicknamed Octopus Trap and documented in detail, abuses how Argo CD hands options to kustomize when it builds a manifest. A crafted request supplies attacker-controlled kustomize settings, including --enable-helm and --helm-command, so the "helm binary" the repo-server runs is a script pulled from a Git repository the attacker controls. No login, no token, no user interaction. Reach the service and you reach a shell on the host.
From one call to the whole cluster
Code execution on the repo-server is bad on its own. What turns it into a cluster takeover is what that box can reach next. The repo-server holds the REDIS_PASSWORD in its environment, and Argo CD caches its rendered manifests and Git references in Redis. With that password, an attacker connects to the cache and rewrites what Argo CD believes your desired state is. Poison the manifest cache and the Git-reference entry, and the application controller does the rest, deploying the attacker's workloads to the cluster on the next sync.
That is the part worth sitting with. The feature that makes Argo CD valuable, a controller that constantly reconciles the cluster back to a declared state, becomes the delivery mechanism the moment the declared state is a lie. The attacker never has to authenticate to the Kubernetes API or run kubectl apply. They let your own automation carry the payload the last mile. GitOps turns its greatest strength against you.
- 1Reach the repo-serverDetection point
- 2Send an unauthenticated manifest requestDetection point
- 3Code runs on the repo-server hostDetection point
- 4Redis password read, cache poisonedDetection point
- 5Cluster syncs the attacker's workloadsDetection point
The default that leaves the door open
Because the repo-server trusts the network rather than the caller, network isolation is the only control that matters, and this is where most installs fall down. Argo CD ships Kubernetes network policies that fence the repo-server and Redis so only its own components can reach them. The official Helm chart leaves them off: the chart's values file creates no network policies unless you turn them on. A large share of Helm-based deployments therefore run with no fence at all around the exact component that runs code for whoever calls it.
That default changes the shape of the risk from a perimeter problem to an assume-breach problem. You do not need an attacker sitting on the public internet. Any workload already inside the cluster can reach an unfenced repo-server: a compromised application pod, a rigged container image, a foothold from an unrelated bug. Argo CD is not the first infrastructure tool to ship its most powerful service open by default, and it will not be the last, but few of them can rewrite your whole cluster on the next sync. The blast radius is everything Argo CD deploys, reachable from a pod that should never have that power.
No CVE means your scanner cannot see this
Vulnerability management usually starts with a version number: match what you run against a list of affected releases, then patch. Here there is no CVE, no advisory ID, and no fixed release to compare against, so a scanner that works by matching versions reports nothing. You cannot patch your way out, and you cannot scan your way to knowing. This one you manage by exposure and by behavior.
Exposure is the first question, and it does not depend on a version at all. Can the repo-server's port and the Redis port be reached from anywhere other than Argo CD's own components? If a pod in an unrelated namespace can open them, you are exposed, full stop. Synacktiv demonstrated the chain against Argo CD 2.13.3 and did not publish the full affected-version range, so treat every reachable repo-server as in scope until the project ships a fix.
Behavior is the second question, and it is where detection earns its place when patching is off the table. Watch the repo-server for what it should never do: spawning a shell, cloning a Git repository you do not recognize, or opening outbound connections to hosts outside your Git provider. Watch Redis for authentication from unexpected sources and for writes to the manifest-cache keys. And watch the application controller for a sync that applies manifests with no matching commit in your repository, which is the signature of a poisoned cache rather than a real change to Git. That last one is the tell that separates this attack from a normal deploy, and it is the same lesson as any unauthenticated internal service you never meant to expose.
Fence the repo-server before a fix arrives
There is no patch date to wait for, so the work is the boundary you build and the monitoring you keep on. In order:
-
Turn on the network policies. If you deployed with Helm, set the chart's network-policy values so it creates them; if you applied manifests directly, apply the policies Argo CD provides. Restrict the repo-server and Redis so that nothing outside Argo CD itself can open them.
-
Confirm neither the repo-server nor Redis is reachable from outside the cluster, and that no unrelated namespace can open their ports. Exposure, not version, is what puts you at risk here.
-
Treat Argo CD as tier-zero. It reads your private repositories, writes to your clusters, and holds deployment secrets, so it deserves the isolation and access control you already give your identity provider. This is the same reasoning that says an insecure default in a cluster component is a design decision, not a footnote.
-
Turn on the behavioral monitoring above and leave it on. With no fix coming, detection is not a backstop to patching. It is the control.
The eighteen-month gap between a private report and a public disclosure with still no fix is its own signal. GitOps controllers now sit at the center of how code reaches production, the same place a reachable service with the keys to everything always draws attackers, but the projects behind them do not always carry the security capacity that centrality demands. Until that changes, the safe assumption is that the tool deploying your clusters can be turned against them, and you build the network, and the alerts, as if it already has been.