News

Unpatched Argo CD Flaw Allows Full Cluster Takeover

An unpatched flaw in Argo CD's repo-server component enables unauthenticated attackers to execute code and potentially take over Kubernetes clusters.

A critical vulnerability in Argo CD's repo-server allows unauthenticated attackers to run code and gain full control of Kubernetes clusters. With no fix available, organizations are urged to isolate their network policies to mitigate risks.

Unpatched Argo CD Flaw Allows Full Cluster Takeover

Argo CD, a popular tool for deploying software to Kubernetes, has been found to have an unpatched vulnerability in its repo-server component. This flaw allows an unauthenticated attacker to execute code if they can access the component's internal network port. The discovery was made by Synacktiv, which reported the issue to Argo CD's maintainers in January 2025. Despite the report, the vulnerability remains unpatched 18 months later, prompting Synacktiv to publish the details to alert users.

The Vulnerability Explained

The bug resides in the repo-server, a component of Argo CD responsible for reading Git repositories and generating Kubernetes manifests. The internal gRPC service of the repo-server lacks authentication, enabling anyone with access to send crafted requests to execute commands. Synacktiv demonstrated this attack on Argo CD v2.13.3 and confirmed that no patched release has been issued.

The attack exploits kustomize, a tool used by Argo CD to convert repository files into manifests. Kustomize includes a --helm-command option that specifies the helm binary to call. Synacktiv discovered that an unauthenticated request to the repo-server's GenerateManifest service could manipulate this option to point to a malicious script hosted in an attacker-controlled Git repository. When kustomize runs, it executes the script instead of helm.

Network Isolation as a Defense

Although the repo-server is intended to operate internally, it is not isolated by default. Argo CD provides Kubernetes network policies to restrict access to the repo-server, but these policies are disabled by default in the Helm chart, a common installation method for Argo CD. This means an attacker who compromises a single pod in the cluster could exploit the vulnerability.

Synacktiv demonstrated that once code execution is achieved on the repo-server, an attacker could read the cluster's Redis password from an environment variable, connect to Argo CD's Redis cache, and manipulate deployment data. This could lead to the deployment of attacker-supplied workloads during the next automatic sync.

Mitigation Steps

With no patched version available, the primary defense is to enforce network isolation. Organizations are advised to enable Kubernetes network policies to ensure that only Argo CD's components can access the repo-server and Redis ports. Argo CD provides the necessary policy files, but Helm users must manually enable them.

To verify the network policies, administrators can use the command kubectl get networkpolicy -A. A secure installation should show one network policy per component, including the repo-server and Redis. If these policies are missing, the repo-server and Redis ports are accessible from the rest of the cluster.

Ongoing Risks

This is not the first time Argo CD has faced security issues. In September 2025, a vulnerability (CVE-2025-55190) allowed an API token with read access to retrieve a project's Git repository credentials. In May 2026, another bug (CVE-2026-42880) enabled read-only users to access plaintext Kubernetes secrets.

Until a patch is released, organizations are urged to treat their cluster networks as potentially hostile and implement strict network isolation to mitigate the risk of exploitation.