Argo CD Misconfiguration Bugs Worth Filing
Argo CD sits on a scary trust boundary: it reads git and applies manifests to Kubernetes. Misconfig there is not a cute XSS. It is "I push YAML, cluster obeys."
Programs that include GitOps UIs expect you to be careful. Good.
Authentication and anonymous surfaces
Hit the Argo CD URL and note the login methods: local admin, OIDC, SAML, GitHub. Default admin with a bcrypt you can find in install docs is rare on mature targets, but forgotten test instances exist. Try account enumeration only within rate limits and rules.
More interesting:
- Dex/OIDC callback issues that attach your IdP user to a privileged Argo group
api/v1/sessionbehaviors and token lifetime- Metrics, swagger, or grpc-web endpoints reachable without the UI cookie
argocd-serverexposed without TLS on an internal hostname you can reach via SSRF
If anonymous user is enabled, list applications and projects. Read-only cluster inventory is already medium on many programs; sync permissions are higher.
Capture the version from the UI or /api/version. Older builds had different default RBAC and settings pages. Knowing the build keeps you from citing fixed issues as if they were novel.
Project isolation and RBAC
Argo CD Projects are supposed to cage which repos, clusters, and namespaces a team may touch. Test with two accounts you own. Can project A sync into project B's namespace? Can you register a repo URL you control and point an app at it?
Proof pattern I like: create or modify an Application (only if policy allows write tests) to deploy a harmless ConfigMap named with your hunter handle into a namespace assigned to you. Sync. Show the object. Revert. That is impact without touching payments or customer pods.
Destination wildcards (* namespaces or clusters) deserve loud callouts. So do cluster secrets that a low-priv UI role can read through the API.
Role JWT tokens minted from the UI sometimes outlive the session you expect. If you can mint a token as a read-only user and still sync, that is the finding—not the existence of tokens.
Git and sync policy traps
Auto-sync plus a writable repo is production deploy as a service. If you can PR to the watched path, the finding may be in SCM; still mention Argo as the enforcer. If webhooks do not verify signatures, argue spoofed sync events only when you can show the server accepts them.
Out-of-bounds git is another classic: an Application sources a public repo path that later becomes attacker-controlled via submodule or redirect. Prefer demonstrating with a repo you own.
Helm value files referenced from Argo can reintroduce secret leakage. If the Application points at a values file with credentials and the UI lets lower roles view live manifests, chain those facts without dumping the secrets into the public report body—use redaction and a canary.
Keep the report operational
Include Argo version, auth mode, project RBAC excerpts, and exact API calls. Recommend SSO with MFA, disabling local admin after bootstrap, tight Projects, repo allowlists, read-only accounts for most humans, and network policies that keep argocd-server off the public internet.
Argo's operator security guide matches this threat model. Cite it when you recommend hardening so the finding feels like shared vocabulary, not fearmongering.