Organizations using Argo CD to automate application deployments on Kubernetes are being urged to review their network configurations after security researchers disclosed an unpatched vulnerability that could allow attackers to execute arbitrary code on the platform's repo-server component and ultimately seize control of an entire Kubernetes cluster.
The vulnerability was identified by French cybersecurity firm Synacktiv, which says the issue affects the repo-server, a core Argo CD service responsible for retrieving application source code from Git repositories and converting it into Kubernetes manifests before workloads are deployed. Because the repo-server sits at the center of the GitOps deployment process, compromising it gives an attacker an opportunity to interfere with how applications are delivered throughout the cluster.
According to the researchers, exploitation does not require authentication. An attacker only needs network access to the repo-server's internal gRPC service, which accepts requests from other Argo CD components but does not verify the identity of the caller. Once that communication channel becomes reachable, a specially crafted request can be used to trigger remote code execution on the vulnerable service.
Synacktiv reported the vulnerability to the Argo CD maintainers in January 2025 through a responsible disclosure process. However, roughly eighteen months later, the issue remains unresolved, with no official security patch or CVE identifier assigned. The researchers chose to disclose their findings publicly to give administrators time to strengthen their deployments while awaiting a permanent fix.
At the center of the attack is Argo CD's repo-server, which continuously retrieves application definitions stored in Git repositories and prepares them for deployment by generating Kubernetes manifests. These manifests describe the desired state of applications, including containers, services, networking, storage, and other deployment configurations that Kubernetes uses to build and manage workloads. Since every deployment passes through this component, gaining control of the repo-server can provide attackers with extensive influence over the software being deployed inside a cluster.
The vulnerability stems from an unauthenticated internal gRPC interface exposed by the repo-server. gRPC is a high-performance communication framework commonly used for communication between services inside distributed applications. In Argo CD's design, the interface is intended for trusted internal communication. However, Synacktiv found that the service performs no authentication checks, allowing any system capable of reaching the port to submit requests that the repo-server will process.
The researchers demonstrated the attack against Argo CD version 2.13.3. They noted that no patched release currently exists and did not publish a complete list of affected versions, leaving administrators without a definitive inventory of vulnerable deployments.
To achieve code execution, the attack abuses Kustomize, a Kubernetes configuration management tool that Argo CD relies on to generate deployment manifests. Kustomize can also invoke Helm, another widely used package manager for Kubernetes, through the "--helm-command" option that specifies which executable should be launched.
Instead of directing Kustomize to the legitimate Helm binary, Synacktiv discovered that an attacker can send a malicious GenerateManifest request instructing it to execute a script stored inside an attacker-controlled Git repository. When Kustomize begins processing the deployment, it unknowingly launches the attacker's script in place of Helm, providing arbitrary code execution within the repo-server environment.
Although the vulnerable interface is intended to remain internal, the researchers warn that internal services should not automatically be considered secure. Kubernetes clusters frequently host dozens or even hundreds of interconnected workloads, and a compromise affecting a single pod can become the starting point for lateral movement if internal communication is not properly restricted.
Argo CD includes Kubernetes NetworkPolicy resources designed to limit access to sensitive services such as the repo-server and Redis. However, Synacktiv found that these protections are disabled by default when Argo CD is deployed using its Helm chart because the "networkPolicy.create" option is set to "false". As a result, installations that rely on the default configuration may unintentionally leave the repo-server reachable from other workloads running inside the cluster.
In such environments, compromising a single pod may be enough for an attacker to contact the repo-server and exploit the vulnerability.
The researchers also demonstrated that remote code execution represents only the beginning of the attack chain. After obtaining execution on the repo-server, they extracted the Redis password stored in an environment variable, authenticated to Argo CD's Redis instance, and modified cached deployment information. When Argo CD later performed its routine synchronization with the Git repository, the poisoned cache caused the platform to deploy an attacker-controlled workload instead of the intended application.
According to Synacktiv, this technique effectively revives a previously addressed weakness tracked as CVE-2024-31989. That earlier vulnerability, discovered by Cycode, exposed Argo CD deployments where Redis lacked password protection, allowing any pod inside the cluster to manipulate deployment cache data. Although Argo CD later introduced Redis password protection to address that issue, the cache contents themselves remain unsigned. By stealing the Redis credentials through the newly disclosed repo-server vulnerability, attackers can once again tamper with deployment data and recreate a similar compromise path.
With no software update currently available, researchers recommend treating network segmentation as the primary line of defense. Administrators should enable Kubernetes NetworkPolicy rules to ensure that only legitimate Argo CD components can communicate with the repo-server and Redis services. Organizations deploying Argo CD through Helm should verify that these policies have been explicitly enabled rather than relying on the chart's default configuration.
Administrators can inspect active network policies by running:
"kubectl get networkpolicy -A"
A properly secured deployment should display dedicated network policies protecting each Argo CD component, including both the repo-server and Redis. Missing policies may indicate that sensitive internal services remain accessible to other workloads inside the cluster.
To help organizations evaluate their exposure, Synacktiv developed a proof-of-concept tool named argo-cdown, capable of automating the complete attack chain. The researchers have postponed its public release to provide defenders with additional time to secure vulnerable environments. The tool is expected to be published on GitHub later, allowing administrators to validate the effectiveness of their own security controls.
The newly disclosed vulnerability is the latest in a series of security issues affecting Argo CD's privileged position within Kubernetes environments. In September 2025, the project patched CVE-2025-55190 after researchers found that an API token with only basic read permissions could retrieve Git repository credentials associated with a project. Several months later, in May 2026, another flaw tracked as CVE-2026-42880 enabled read-only users to access plaintext Kubernetes secrets.
Taken together, these incidents point to a recurring challenge rather than isolated implementation flaws. Argo CD occupies one of the most privileged positions within Kubernetes deployments, maintaining access to source repositories, deployment pipelines, cluster resources, and sensitive credentials. As a result, weaknesses affecting its internal services can quickly become pathways to broader infrastructure compromise.
Until an official patch becomes available, organizations should assume that internal cluster traffic cannot always be trusted. Restricting communication between workloads, enabling Kubernetes NetworkPolicy protections, and limiting access to critical Argo CD services remain the most effective measures for reducing exposure to this newly disclosed attack technique.
