Argo CD flaw shows why GitOps infrastructure should be treated as tier zero

A newly disclosed vulnerability in Argo CD is drawing attention to the security risks of GitOps platforms, with researchers warning that the flaw could allow attackers who gain a foothold inside a Kubernetes cluster to execute code and manipulate application deployments.

Security firm Synacktiv said in a report that the flaw affects Argo CD’s repo-server component, which fetches content from Git repositories and generates Kubernetes manifests used to deploy resources in a cluster. Argo CD is one of the most popular Kubernetes tools and is based on the GitOps paradigm.

“Argo CD requires significant privileges within the cluster,” Synacktiv said. “Additionally, it has access to private Git repositories, making it an attractive target for attackers.”

The issue centers on the repo-server’s unauthenticated GenerateManifest gRPC endpoint. Synacktiv said an attacker able to reach that endpoint could supply Kustomize options in a manifest generation request and abuse Kustomize’s Helm-related build options to execute attacker-controlled commands.

Exploitation requires access to both the repo-server gRPC port and the Redis database port, which should not be exposed to users. Argo CD provides Kubernetes network policies designed to prevent that scenario, but those protections are not enabled by default in Helm chart deployments, according to Synacktiv.

In such deployments, compromising a single pod inside the cluster could be enough to give an attacker the internal access needed to exploit the vulnerability.

Synacktiv said it was able to use the flaw to obtain the Redis password from the repo-server environment and access Argo CD’s Redis database. The researchers then manipulated cached deployment data, allowing a malicious manifest to be deployed automatically when Argo CD’s Auto Sync feature was enabled.

If Auto Sync is not enabled, exploitation would require a user to manually sync the application.

Synacktiv publicly disclosed the details on July 1 after first reporting the issue to Argo CD maintainers in January 2025. The vulnerability remains unpatched, and the firm recommended strict Kubernetes network policies to block untrusted pods from reaching the repo-server and Redis services until a fix is available.

Assessing internal cluster exposure

For CISOs, the key question is not only whether Argo CD is exposed to the internet, but whether other workloads inside the Kubernetes cluster can reach its internal services.

“Because the repo-server’s gRPC service does not enforce authentication, any pod that can reach it becomes equivalent to an authenticated attacker,” said Devashri Datta, a cybersecurity researcher. “In a typical cluster, that means any compromised application pod, misconfigured service mesh, or adjacent workload with local code execution can directly query the GenerateManifest endpoint or hit the Redis cache, no internet exposure required.”

Organizations should not equate “not internet-facing” with “low risk,” because modern attacks often begin with the compromise of an internal workload, according to Sakshi Grover, senior research manager for cybersecurity services research at IDC Asia/Pacific.

“CISOs should therefore evaluate which workloads can communicate with the Argo CD control plane, whether east-west traffic is appropriately segmented, and whether unnecessary trust relationships exist between application workloads and GitOps infrastructure,” Grover said. “The assessment should focus on attack paths rather than perimeter exposure.”

Treating GitOps as tier-zero

The flaw also underscores the role GitOps platforms play in controlling software deployment across enterprise infrastructure.

“GitOps engines aren’t utility services; they’re tier-0 control-plane components,” Datta said. “By design, Argo CD holds read access to private repositories, sync/write access to target clusters, and custody of deployment secrets. It sits at the precise intersection of source code, configuration management, and live infrastructure.”

That level of access means an Argo CD compromise may extend beyond a single application. An attacker could turn the platform used to deploy applications into a channel for malicious manifests, while also interfering with auto-sync behavior and extracting credentials cached in supporting systems such as Redis.

A compromise of these platforms could influence software delivery at scale, making them strategic assets that should be subject to stricter governance and privileged access controls similar to those applied to identity platforms and other critical management systems.

The article originally appeared on CSO.