Argo CD: GitOps With Default Admin

The default admin password is the pod name

Argo CD, the most popular GitOps continuous delivery tool for Kubernetes, ships with a default admin password that is set to the name of the argocd-server pod. On a standard Helm installation, this means the admin password is something like argocd-server-6b7f8d5c4b-x2k9p. Anyone who can read pod names (which includes anyone with basic Kubernetes RBAC or access to the namespace) knows the admin password.

The Argo CD documentation notes that you should change this password after installation. Many teams do not. In our assessments, approximately 30% of Argo CD installations we encounter still use the default pod name password. On instances exposed to the internet, that number rises because these are typically quick demo or staging deployments that never got hardened.

/api/v1/applications: your entire infrastructure

The /api/v1/applications endpoint returns every application managed by Argo CD. Each application entry includes:

• Git repository URLs: the source repositories for all deployments, including private repos
• Helm values: the full values.yaml content, which frequently contains database passwords, API keys, and service account tokens
• Target cluster and namespace: where each application is deployed
• Sync status and health: real-time state of every deployment
• Resource tree: every Kubernetes resource (Deployments, Services, ConfigMaps, Secrets) managed by the application

The Helm values are the most dangerous exposure. Development teams treat values.yaml files as configuration, not as secret storage, so they embed credentials directly:

database:
  host: prod-db.internal.company.com
  username: app_user
  password: Pr0d_DB_P@ssw0rd!
redis:
  url: redis://:cache_secret_123@redis.internal:6379
aws:
  accessKeyId: AKIAIOSFODNN7EXAMPLE
  secretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

A single API call to /api/v1/applications dumps all of this.

/api/v1/repositories: git credentials

The /api/v1/repositories endpoint returns every git repository configured in Argo CD, along with the authentication credentials used to access them. This typically includes:

• GitHub/GitLab personal access tokens with repository read access
• SSH private keys used for git clone operations
• Username/password combinations for HTTPS git access

These credentials provide access to the source code repositories for every application the organization deploys through Argo CD. On most teams, this means access to the entire codebase.

/api/v1/clusters: Kubernetes credentials

The /api/v1/clusters endpoint returns every Kubernetes cluster registered with Argo CD, including:

• Cluster API server URLs: internal and external endpoints
• Service account tokens: the bearer tokens Argo CD uses to deploy to each cluster
• TLS certificates: client certificates for cluster authentication
• Cluster metadata: Kubernetes version, node count, and namespace listing

With the service account tokens from this endpoint, an attacker can authenticate directly to each Kubernetes cluster with whatever RBAC permissions the Argo CD service account has been granted. In most installations, Argo CD has cluster-admin privileges because it needs to create and manage resources across all namespaces.

The full chain

1. Discover Argo CD on the default port 443 or 8080. The login page identifies itself as Argo CD with version information.
2. Authenticate with admin and the pod name (guessable from the Helm release name pattern) or use default credentials admin:argocd-server-[hash].
3. Dump /api/v1/applications to harvest every credential embedded in Helm values across all managed applications.
4. Dump /api/v1/repositories to obtain git access tokens for the entire codebase.
5. Dump /api/v1/clusters to obtain Kubernetes service account tokens for every registered cluster.
6. Access production clusters directly using the harvested service account tokens. Deploy a privileged pod to escape to the node.

From a single Argo CD instance, you can compromise every Kubernetes cluster it manages, every git repository it reads from, and every secret embedded in the application configurations.

How common is this?

Shodan indexes over 12,000 internet-facing Argo CD instances as of early 2026. Many are staging or demo environments, but plenty are production deployments that manage real infrastructure. The Argo CD project issued CVE-2022-29165 (authentication bypass) and CVE-2024-31989 (credential exposure), but the most common vulnerability is simply the default password that nobody changed.

Defense

• Change the admin password immediately after installation: argocd account update-password
• Disable the admin account entirely and use SSO/OIDC for all access
• Enable RBAC so that users and service accounts only see the applications they need
• Never expose Argo CD to the internet without a VPN or zero-trust proxy
• Use Argo CD's built-in secret management with external secret operators (HashiCorp Vault, AWS Secrets Manager) instead of embedding credentials in Helm values
• Audit /api/v1/repositories and rotate any exposed git credentials
• Use Kubernetes RBAC to limit the Argo CD service account to the minimum required permissions per namespace