The Argo CD Vulnerability That Spreads From One Pod to Your Entire Cluster

Argo CD has an unpatched security flaw that lets an attacker take over a Kubernetes cluster, and it has been known for 18 months.

Argo CD is one of the most widely used tools for deploying apps onto Kubernetes. Security firm Synacktiv found this flaw and reported it privately to the maintainers in January 2025. There is still no official fix, as of this writing in July 2026. No CVE has even been assigned. If you run Argo CD, this affects you directly, and the fix is something you have to do yourself, today, not something you can wait for a vendor to ship. (The Hacker News coverage is a good plain summary if you want the news version.)

This post explains what Argo CD actually is, what went wrong, and the one thing you can check right now to protect yourself even without a patch.

First, what is Argo CD?

Most teams that use Kubernetes do not manually type commands to deploy their apps. Instead, they store their app's desired setup as files in a Git repository, and a tool watches that repository and applies changes automatically. This approach is called GitOps.

Argo CD is one of the most popular tools for doing this. You push a change to Git, and Argo CD notices, pulls the new files, and updates your Kubernetes cluster to match. It is trusted, widely used, and normally treated as a helpful robot working quietly in the background.

The piece that broke: repo-server

Argo CD is made of several smaller parts working together. One of them is called repo-server. Its job is simple: read the files from your Git repository and turn them into the final instructions Kubernetes understands.

To do this job, repo-server sometimes uses a tool called kustomize, which helps combine and customize configuration files. Kustomize, in turn, can call out to another tool called Helm to handle a specific kind of configuration package.

Here is the part that matters: kustomize lets you specify exactly which program it should use when it needs Helm, through a setting called --helm-command. Normally this points to the real Helm program. Nothing suspicious about that on its own.

What went wrong

The repo-server component was never checking who was allowed to talk to it internally. There was no login step, no permission check. Anything that could reach it and get it to process a Git repository set up a specific way could hijack what repo-server ran.

One thing to be clear about: this is not an attacker coming in from the internet. In a normal install, repo-server is only reachable from inside the cluster, not exposed to the outside world. The realistic attacker here is something already running inside your cluster, a compromised pod, a leaky application, another workload that got popped, that can quietly reach repo-server because nothing is stopping pods from talking to each other by default. That detail is the whole reason the fix later in this post looks the way it does. Security firm Control Plane makes this exact point in their analysis, aptly titled Internal ≠ Isolated.

The other thing that matters: this only triggers when an Application is configured to use Kustomize's Helm chart support, where Kustomize renders a Helm chart as part of building the final manifests. Researchers found that an attacker could send repo-server a crafted request that overrode the --helm-command setting, the setting that tells Kustomize which program to run as "Helm." Instead of the real Helm program, it pointed to a script from a Git repository the attacker controlled. Synacktiv walks through exactly how they found and built this, including the GenerateManifest request they crafted, in their full technical writeup.

When repo-server tried to run "Helm," it actually ran the attacker's script instead. And just like that, the attacker's own code was running inside your infrastructure.

Why that is such a big deal

Once an attacker can run their own code on repo-server, they are not stuck there. Repo-server sits close to the middle of your deployment pipeline, and that comes with access to sensitive things nearby:

• It can read the credentials repo-server holds to do its job, which is a real prize: this is the component that clones your private Git repositories and pulls your private Helm charts, so it has the access tokens and keys for all of them. It also holds the password for Redis, which Argo CD uses as an internal cache.
• It can poison that cache directly. Argo CD stores already-rendered manifests in Redis so it does not have to redo the work of building them from Git every single time.
• The next sync does not always re-read Git and re-render from scratch. If the cache says "here is the manifest to apply," Argo CD can end up applying whatever the attacker planted there instead, without ever touching your real Git repository.

Put plainly: what starts as "I can run one script" can turn into "I now control what runs on your entire Kubernetes cluster."

The part that should worry you most: there is no patch

Normally a story like this ends with "and then the vendor released a fix, so update now." Not here.

Synacktiv reported this privately in January 2025. As of the article covering this in July 2026, there is still no official patched version. The people who found it even built and held back a tool called argo-cdown that automates the full attack, specifically to give organizations more time to protect themselves before releasing it so admins can test their own deployments. This is also why some in the industry now argue GitOps infrastructure like Argo CD should be treated as tier-zero, meaning as sensitive as your identity provider or your cluster's control plane itself.

That is an unusually long gap, and it means "just update Argo CD" is not an option right now. You need a different kind of defense.

The one setting that actually protects you

The real safety net here is not a patch. It is a basic Kubernetes feature that is often left switched off: network policies.

A network policy is a rule that controls which parts of your cluster are allowed to talk to which other parts. Without one, anything inside your cluster can usually reach anything else inside your cluster. With one in place, you can say "only these specific components are allowed to talk to repo-server," and everything else gets blocked.

Network policies are not something specific to Argo CD. They are a standard Kubernetes feature, and it is your cluster's networking layer (called a CNI plugin, examples include Calico and Cilium) that actually enforces them. Argo CD's own official Helm chart has a convenient flag that generates these network policy rules for you, scoped to Argo CD's own components, and that flag ships turned off by default. Most installations never turn it on.

One thing to check before you rely on this: not every Kubernetes networking setup enforces network policies at all. Some common ones, like a plain Flannel setup, silently ignore them. Turning the flag on will still create the policy objects, but they will do nothing to protect you unless your cluster's networking layer actually enforces them. Confirm that first, then enable the flag.

That default setting being off is a real part of why this bug is dangerous in practice. Remember, the attacker here is another workload inside your cluster, not someone on the internet. If repo-server and its Redis instance would only accept connections from the other Argo CD components that legitimately need them, a random compromised pod elsewhere in the cluster would have no path to reach the vulnerable part in the first place.

What to actually do about it

You can check your own cluster right now with one command:

kubectl get networkpolicy -A

If that comes back mostly empty, or missing anything protecting Argo CD's components, you are likely running exposed.

To fix it:

1. Confirm your cluster's networking layer actually enforces network policies. Calico, Cilium, and most managed Kubernetes CNIs do. Plain Flannel does not, so check yours before assuming you are covered.
2. Turn on the network policy flag in your Argo CD Helm chart configuration. It is usually a simple flag, not a rebuild, and it will generate the right rules scoped to Argo CD's own components.
3. Make sure repo-server and Redis only accept connections from the other Argo CD components that genuinely need to reach them.
4. Check this regularly. A network policy that gets accidentally removed during a future upgrade is a silent way to end up exposed again without noticing.

None of this requires a patch that does not exist yet. It requires flipping a setting that should probably have been on by default in the first place.

The whole post in three lines

• Argo CD's repo-server component has no internal authentication, so any workload already inside your cluster (not an internet attacker) can send it a crafted request that swaps in a malicious script disguised as the Helm tool and runs their own code inside your pipeline.
• From there, an attacker could read credentials and poison Argo CD's internal manifest cache, getting their own workloads deployed on the next sync without ever touching your real Git repository, and there is still no official patch 18 months after it was reported.
• The real fix available today is enabling Kubernetes network policies (and confirming your cluster's networking layer actually enforces them), which are off by default in Argo CD's Helm chart, so check yours with kubectl get networkpolicy -A and lock down repo-server's access.

A tool you trust to deploy your apps is still worth checking on, especially when the fix is a setting you can flip today.

Sources and further reading

• Synacktiv: Caught in the Octopus Trap, Unauthenticated RCE in Argo CD with CodeQL. The original technical writeup from the researchers who found it.
• The Hacker News: Unpatched Argo CD Repo-Server Flaw Could Let Attackers Take Over Kubernetes Clusters. The plain-language news summary.
• Control Plane: Internal is not Isolated (Or Secure). A deeper security analysis of why in-cluster reachability is the real problem here.
• CSO Online: Argo CD flaw shows why GitOps infrastructure should be treated as tier zero. The broader "treat your deployment tooling as critical infrastructure" argument.