CVE-2025-55190 in Argo CD: Patch Posture & SBOM Response

On September 4, 2025, the Argo CD maintainers published GHSA-2hj5-g64g-fp6p disclosing CVE-2025-55190, a critical credential-disclosure vulnerability in the project details API. The CVSS v3.1 base score is 9.9. The advisory describes a low-privileged API token with get rights on a project being able to read repository credentials (HTTPS basic auth tokens, SSH private keys, OAuth tokens) for any Git repository the project references. Argo CD has become the dominant GitOps controller in Kubernetes-heavy organizations, and credential disclosure here cascades directly into source-code repository compromise, then to CI/CD takeover, then to production deployment manipulation. This is the GitOps equivalent of the 2023 CircleCI breach but with Kubernetes-cluster blast radius added.

What does the vendor advisory say?

The Argo CD advisory describes CVE-2025-55190 as missing access control on the /api/v1/projects/{name}/detailed endpoint. The endpoint was designed to return project metadata for UI rendering, but it inadvertently included the spec.sourceRepos configuration with embedded credentials in cleartext. Any token with project, get permission — a low-privilege role frequently granted to read-only auditors, junior developers, and reporting integrations — could fetch credentials for every Git repository the project synced from. Maintainers credit researcher Ben Burgess for coordinated disclosure. The fix in 2.13.9, 2.14.16, 3.0.14, and 3.1.2 redacts credential fields before returning the JSON payload and enforces stricter RBAC on the endpoint, requiring repositories, get (a separately-grantable permission) to view credential fields.

Which versions are affected and which are patched?

CVE-2025-55190 affects:

• Argo CD 2.13.0 through 2.13.8 — fixed in 2.13.9
• Argo CD 2.14.0 through 2.14.15 — fixed in 2.14.16
• Argo CD 3.0.0 through 3.0.13 — fixed in 3.0.14
• Argo CD 3.1.0 through 3.1.1 — fixed in 3.1.2

Versions before 2.13.0 are out of maintenance and will not receive a fix; operators on those versions must upgrade. Verify the running version with argocd version --short --client=false from the CLI or check the controller pod image tag in kubectl get pod -n argocd argocd-server-0 -o jsonpath='{.spec.containers[0].image}'.

Common distribution channels:

• Helm chart argo/argo-cd versions 7.6.10 and 7.7.5 pin to the patched controller images.
• Operator SDK installs (argoproj-labs/argocd-operator) ship 0.12.1 with the patched controller default.
• OpenShift GitOps 1.16.1 carries Argo CD 2.14.16 and addresses both CVE-2025-55190 and the related CVE-2025-13888 (OpenShift GitOps privilege escalation).

Is it in CISA KEV and what is the EPSS score?

CVE-2025-55190 is not currently in CISA KEV. EPSS at publication was 0.06, climbing to 0.14 over the following month. The reason this CVE deserves urgency despite the modest EPSS is the credential-exfiltration outcome — every exposed repository token is a live credential that grants attacker access to the underlying Git host. CISA's 2025 advisory on GitOps security (CSA-25-GITOPS-01, published August 11, 2025) explicitly warned that "GitOps controllers are emerging as a high-value pivot point for supply-chain intrusions" and recommended treating GitOps RBAC bugs with the same urgency as identity-provider CVEs.

How do you find vulnerable instances in your SBOM?

Argo CD installations appear in cluster SBOMs as the argocd-server, argocd-application-controller, argocd-repo-server, and argocd-redis-ha-haproxy images. Safeguard saved query:

# Identify Argo CD installations below the fixed versions
safeguard scan --cve CVE-2025-55190 --product argo-cd

# Show GitOps controllers that hold Git repository credentials
safeguard assets list \
  --filter "vendor=argoproj AND product=argo-cd AND feature=git-credentials" \
  --include-cve CVE-2025-55190

For shops without Argo-specific SBOM tooling, the lightest enumeration is kubectl get pods -A -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | grep argocd joined against the fixed-version table. The Argo CD project also ships an argocd admin cluster shards CLI command that lists every controller registration; cross-reference against the patched-build list.

What is the recommended patch rollout?

Argo CD maintainers recommend:

1. Snapshot the Argo CD configuration (kubectl get all,configmap,secret -n argocd -o yaml > argocd-backup.yaml).
2. Update the Helm chart values or operator CR to pin the patched image (appVersion: 2.14.16 or equivalent).
3. Apply the upgrade (helm upgrade argocd argo/argo-cd -n argocd --version 7.7.5 or kubectl apply -f argocd-operator-cr.yaml).
4. Wait for the rolling restart to complete; verify with kubectl rollout status deployment/argocd-server -n argocd.
5. Re-confirm versions via argocd version.
6. CRITICAL POST-PATCH STEP: rotate every repository credential Argo CD held. Because the advisory documents reachable credential disclosure, defenders must assume any historical low-privilege token holder may have already harvested credentials. Generate new tokens or SSH keys for each Git repository, update the Argo CD Secret resources, and revoke the old credentials at the Git host.
7. Audit Argo CD's audit log for /api/v1/projects/*/detailed calls in the exposure window; investigate any caller outside the expected UI/CLI client list.

Compensating control while patching: tighten Argo CD RBAC immediately. Remove the project, get permission from any role that does not absolutely need it. Restrict the API server's NetworkPolicy to allow only the Argo CD UI ingress and trusted CI agents. Implement an admission webhook that denies Project resource modifications outside a defined change-management workflow.

What detections does the vendor or CISA publish?

The Argo CD maintainers' advisory recommends scanning the audit log for project details API calls. Datadog Security Labs and Sysdig Secure both published Falco rules for the access pattern within 72 hours of disclosure. A vendor-supplied detection imported from the Argo CD security wiki:

# Source: Argo CD security wiki, GHSA-2hj5-g64g-fp6p, 2025-09-04
title: Argo CD Suspicious Project Details API Access
status: stable
logsource:
  product: argocd
  service: audit
detection:
  selection:
    request_path|contains: '/api/v1/projects/'
    request_path|endswith: '/detailed'
    response_code: 200
  filter_legit_clients:
    user_agent|startswith:
      - 'argocd-cli/'
      - 'argocd-server/'
  condition: selection AND NOT filter_legit_clients
fields:
  - subject
  - request_path
  - source_ip
  - user_agent
  - response_size
level: high

CrowdStrike Cloud Security and Wiz published cluster-scoped queries that highlight Argo CD installations exposing the API endpoint without ingress authentication, which is the deployment pattern that most magnifies the CVE's blast radius.

Beyond CVE-2025-55190 specifically, the broader GitOps hardening agenda for 2026 includes: enforcing short-lived OIDC-issued tokens for Git access (no long-lived PATs in Argo CD Secret resources); using Sealed Secrets, SOPS, or External Secrets Operator so credentials are not stored cleartext in any Argo CD-readable resource; deploying Argo CD with a dedicated Kubernetes namespace whose ServiceAccount cannot read cluster-wide Secrets; and pairing Argo CD with a policy engine (Kyverno, OPA Gatekeeper) that admission-validates every synced manifest. Combined with patching CVE-2025-55190, these structural controls prevent the next disclosure in the same class of bug from becoming an equivalent emergency.

For organizations evaluating GitOps tooling more broadly, the Argo CD security review process now mirrors what banks do for SWIFT terminals: documented privileged-access workflows, periodic credential rotation, change-window-only modifications, and audit-log retention beyond standard application logs.

How Safeguard Helps

Safeguard ingests Argo CD installation manifests from every Kubernetes cluster registered through the SCM integration, matching image tags against the fixed-version table for CVE-2025-55190. Policy gates fail change-management promotions of new clusters where the GitOps controller is below the patched build. Griffin AI scores Argo CD installations by credential blast radius — the count of distinct Git repositories with stored credentials, the privilege scope of those credentials (read-only deploy keys vs. push-capable PATs), and the count of distinct projects that reference shared credentials — surfacing the highest-risk installations first. VEX statements from the Argo CD maintainers are auto-ingested for installations with RBAC configurations that block the affected endpoint at the network or policy layer. The remediation engine generates per-cluster runbooks for the Helm chart upgrade, the post-patch credential-rotation workflow, and the audit-log query that defenders need to confirm no historical disclosure happened — closing the loop between SBOM detection, patch, and credential hygiene.