Every ops team has that one internal service. The one that only ever talks to other internal services, so nobody ever really locked the door on it. "It's not exposed," goes the thinking. "Nothing outside the cluster can reach it, so why would it need auth?"
A French security shop called Synacktiv just spent an entire article dismantling that assumption, and the target was Argo CD.
Quick context if you're not running it: Argo CD is the GitOps tool a huge share of Kubernetes shops deploy through. By Argo's own 2023 survey, 93% of respondents run it in production. One of its components, the repo-server, pulls your manifests from Git and hands them off to be deployed. It's "internal only," which is Argo CD's way of saying: trust the network, not the caller.
Synacktiv checked that trust model. The repo-server's gRPC endpoint, the one that generates manifests, requires zero authentication. None. Anyone who can reach it can ask it to build manifests, and it will comply.
Fine, you might say. Kustomize is just rendering YAML. What's the worst it can do?
Kustomize has a --helm-command flag that points it at whatever binary you tell it to run. Point that at a script instead of Helm, pull the script from a Git repo you control, and Kustomize executes your code instead of building your manifest. That's unauthenticated remote code execution on the repo-server. No login. No CVE, even now, eighteen months after Synacktiv reported it privately.
And they didn't stop at "we got a shell." They used that access to steal the Redis password sitting in an environment variable, log into Argo CD's own cache, and quietly plant a poisoned manifest under the entry Argo CD checks on every auto-sync. Roll the cached Git ref back a commit, wait for Argo CD to notice the "newer" HEAD, and it pulls the poisoned manifest straight out of cache and deploys it like it's the most routine thing in the world. Full cluster takeover, and Argo CD does the deploying for you.
Here's the part that should actually bother you. Argo CD ships network policies built specifically to wall the repo-server off from everything except its own components. They exist. They work. If you installed Argo CD through the Helm chart (and be honest, most of you did), those policies default to off: networkPolicy.create: false. Out of the box, one compromised pod anywhere in your cluster is one gRPC call away from your repo-server.
I don't care how deep in the cluster a service sits. If it can execute commands on your behalf, it needs authentication. "Internal" is not a security control. It's a networking diagram.
Your actual to-do list, not the theoretical one:
Run kubectl get networkpolicy -A right now. Confirm argocd-repo-server-network-policy and argocd-redis-network-policy actually exist in your argocd namespace. If you installed via Helm and never touched networkPolicy.create, they probably don't.
If they're missing, fix it today. This isn't a next-sprint item. It's a values.yaml flag and a helm upgrade.
Rotate your Redis password regardless. If it's ever sat in a repo-server environment variable an attacker could theoretically reach, treat it as already burned.
Go back to that "internal only" service from the opening line. Check what it's actually allowed to talk to. "Nobody can reach it" and "nothing can reach it" are two very different claims, and only one of them is a security control.
Source: Synacktiv's original disclosure, "Caught in the Octopus Trap" (July 1, 2026), with additional confirmation from The Hacker News.
