Argo CD, one of the most widely adopted GitOps tools for deploying applications to Kubernetes environments, has been found to contain an unpatched security flaw in its repo server component that could allow attackers to execute arbitrary code and potentially take over an entire Kubernetes cluster. The issue was disclosed by cybersecurity firm Synacktiv, which warned that the vulnerability remains unresolved despite being responsibly reported to the project’s maintainers in January 2025. Nearly eighteen months later, no official patch or CVE identifier has been assigned, prompting the researchers to publicly disclose the technical details so organizations can implement defensive measures. According to Synacktiv, the flaw can be exploited by an unauthenticated attacker who is able to access the repo server’s internal network port, creating a serious security risk for deployments where internal network access is not properly restricted.
The vulnerability exists within Argo CD’s repo server, a component responsible for retrieving Git repositories and generating Kubernetes manifests that define application deployments. Synacktiv explained that the internal gRPC service exposed by the repo server does not require authentication, allowing anyone with network access to submit specially crafted requests to the GenerateManifest service. During testing on Argo CD version 2.13.3, the researchers demonstrated that attackers could abuse Kustomize, a standard utility used by Argo CD to generate deployment manifests. Kustomize includes a configuration option called helm command, which normally specifies the Helm binary to execute during manifest generation. However, the researchers discovered they could manipulate this option to point to a malicious script stored inside an attacker controlled Git repository. When the manifest generation process runs, Kustomize executes the malicious script instead of the legitimate Helm binary, effectively granting attackers remote code execution on the repo server. Synacktiv noted that while it confirmed exploitation against version 2.13.3, it has not released a complete list of all affected versions because no patched release currently exists.
Although the vulnerable gRPC service is intended for internal communication, Synacktiv emphasized that many deployments leave it exposed within the Kubernetes environment. Argo CD includes Kubernetes network policy templates designed to isolate the repo server from unauthorized communication, permitting access only from trusted Argo CD components. However, the researchers found that installations performed through the official Helm chart leave these protections disabled by default because the networkPolicy.create option is set to false. In such configurations, compromising even a single pod within the Kubernetes cluster could provide an attacker with access to the repo server and enable exploitation of the vulnerability. Synacktiv further demonstrated that gaining code execution on the repo server allows attackers to retrieve the Redis password stored in an environment variable, connect to Argo CD’s Redis cache, and modify cached deployment information. During the next automatic synchronization process, Argo CD would deploy attacker supplied workloads, resulting in a complete compromise of the Kubernetes environment.
The researchers also highlighted that this attack effectively revives the impact of CVE 2024 31989, a vulnerability disclosed by Cycode in 2024 that allowed deployment cache poisoning because Redis lacked password protection. Although Argo CD addressed that issue by introducing Redis authentication, Synacktiv pointed out that deployment data stored in Redis is still not cryptographically signed. As a result, attackers who recover the Redis password through the newly disclosed vulnerability can once again manipulate cached deployment data and achieve similar results. Since there is currently no software update available to resolve the issue, Synacktiv recommends organizations focus on strengthening network isolation by enabling Kubernetes network policies so only authorized Argo CD components can communicate with the repo server and Redis services. Administrators can verify existing protections by running the command kubectl get networkpolicy -A, where properly secured deployments should display dedicated network policies for each Argo CD component, including the repo server and Redis. The researchers have also developed a proof of concept tool named argo cdown to automate the attack chain but have delayed its public release to provide organizations with time to secure their environments before publishing it on GitHub for defensive testing. The disclosure follows previous Argo CD security issues, including CVE 2025 55190, patched in September 2025, which exposed Git repository credentials through low privilege API tokens, and CVE 2026 42880, disclosed in May 2026, that allowed read only users to access plaintext Kubernetes secrets. These recurring issues continue to draw attention to the security of internal services that manage sensitive cluster resources and deployment credentials.
Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem.
