Critical failure on Argo CD exposes code execution without authentication and could compromise the cluster

Argo CD, the most commonly used declarative tool to deploy applications in Kubernetes, drags a critical failure without patch into its component rest that allows to run code without authentication provided that an attacker can reach the internal port of the service. The security firm Synacktiv published the details after reporting vulnerability in January 2025 and waiting for an arrangement without success; according to its evidence, the operation can lead to total cluster taking.

The technical core of the problem is simple but dangerous: repo-server internally exposes a gRPC service without authentication and its call GenerateManifest allows to control the --helm-command option of kustomize, the tool that Argo CD uses to convert Git repositories into Kubernetes manifests. Synacktiv showed that an unauthenticated request can point that option to a script hosted in a repository controlled by the attacker; when kustomize runs what he thinks is "help," he runs the malicious script and the attacker gets code execution in the rest pod-server.

This vulnerability would not be so exploitable if the cluster network was segmented, but the operational problem aggravates the risk: Argo CD's Helm chart leaves NetworkPolicies disabled by default(networkPolicy.create = false), which means that any committed pod within the cluster can reach the internal repo-server ports. Synacktiv also chained the remote execution with another weakness in cache management: reading the password of Reds from environment variables connected to the Argo CD Reds and "poisoned" the cache of deployments, causing the next automatic synchronization to deploy charges from the attacker. This sequence revives previous problems where the cache was not signed and depended on secrets that could be exfiltered or reused.

The implications are clear: Argo CD concentrates access to repositories and secrets and its internal surfaces have repeatedly given greater access to the necessary. In 2025 and 2026, other errors were corrected that allowed to read credentials or secrets with low-privileged tokens, and the trend has been the same: internal component failures that facilitate climbing to compromise full deployments.

As long as there is no official patch (no corrected version or public CVE associated with Synacktiv report), the only practical defense is to treat the cluster network as hostile and apply immediate isolation. Activate Kubernetes network policies to prevent any non-Argo CD pod from reaching the rest-server and Reis ports, and confirm their status with commands like kubectl get networkpolicy -A. If you installed Argo CD with Helm, enable chart policies (e.g., networkPolicy.create = true) or implement its own restrictive NetworkPolicies that allow traffic only between the official components of Argo CD.

In addition to network isolation, it is appropriate to take additional operational measures: rotate the passwords and sensitive secrets (including the Reis password exposed), disable automatic synchronization until the integrity of the repository and cache is verified, inspect the pods and images in search of unusual processes and outgoing connection records, and apply additional postage controls such as admission policies (OPA / Gatekeeper or Kyverno), CI image scanning and performance-time detection (e.g. Falco). For rapid inspection of the installation, check Argo CD services and pods with kubectl get svc -n argocd and kubectl get pops -n argocd -o yaml to locate sensitive environment variables.

Synacktiv created a tool called argo-cdown that automates the entire attack chain and, responsibly, has delayed its publication to give administrators time to park their networks before it becomes massively exploitable; it is appropriate to follow its channel and that of the Argo CD project to receive alerts and patches. For technical reference and to obtain the policies and values of the chart you need to activate, see the official documentation and repositories of Argo CD in GitHub and the Kubernetes Network Policies guide: https: / / github.com / argoproj / argo-cd, https: / / www.synacktiv.com / and https: / / kubernetes.io / docs / concepts / services-networking / network-policies /.

In short, until Argo CD publishes a patch, teams must assume that the cluster network is the most dangerous vector, apply strict isolation between applications and control platforms, audit and rotate secrets, and prepare detection and response for handling signals in the deployment cache. This incident is a reminder that the platforms of continuous delivery and reconciliation, by their very nature, concentrate privileges and require in-depth defence controls in both network and identity and telemetry.