CVE-2025-55190: Critical Information Disclosure in Argo CD Project API

Argo CD, a declarative continuous delivery tool for Kubernetes, suffers from a critical information disclosure vulnerability tracked as CVE-2025-55190. The vulnerability resides in the Project Details API endpoint, which is used to retrieve aggregated configurations for specific Argo CD projects. Authenticated users with minimal read access to a project can exploit this flaw to expose sensitive backend credentials.

The exposure occurs because the API endpoint serializes and returns complete backend objects without applying appropriate sanitization filters. Specifically, the system fails to redact authentication materials such as bearer tokens, basic authentication passwords, and Git repository credentials stored within the project scope. This violates the intended Role-Based Access Control (RBAC) boundaries.

As a result, tokens or users possessing only standard projects, get permissions can access secrets they are not explicitly authorized to view. The flaw impacts multiple branches of the Argo CD codebase, spanning versions 2.13.0 through 3.1.1. The severity is marked as critical (CVSS 9.9) due to the low attack complexity and the potential to compromise connected Kubernetes clusters and Git infrastructure.

The root cause of CVE-2025-55190 is a CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) flaw located in the data serialization pipeline of the GetDetailedProject API handler. When a client requests the /api/v1/projects/{project}/detailed endpoint, the server retrieves the associated Repository and Cluster data structures from the underlying datastore.

In vulnerable versions, the handler returns these objects directly to the client in their raw, unsanitized state. The standard data models for Kubernetes clusters and Git repositories within Argo CD contain embedded credential fields. For clusters, this includes BearerToken, Password, and ExecProviderConfig. For repositories, it includes raw usernames and passwords used for Git authentication.

The application logic relied on general API access controls rather than explicit, object-level field redaction. Because users with projects, get permissions are legitimately allowed to view the configuration structure of a project, the authorization check passes. The system fails to apply a secondary check or a data transfer object (DTO) transformation to strip the sensitive fields before JSON serialization, resulting in the plain-text disclosure.

Analysis of commit e8f86101f5378662ae6151ce5c3a76e9141900e8 reveals the exact mechanism used to rectify the missing sanitization. The developers introduced and enforced the usage of .Sanitized() methods on both Repository and Cluster objects within pkg/apis/application/v1alpha1/.

In the vulnerable implementation, the server/project/project.go handler retrieved the cluster list and passed it directly to the response builder. The patch modifies this by explicitly iterating over the retrieved objects and replacing them with their sanitized counterparts before constructing the final response.

// Vulnerable Implementation Pattern
func (s *Server) GetDetailedProject(...) {
    // ... authorization checks ...
    projectClusters, err := s.db.GetProjectClusters(ctx, projectName)
    // projectClusters is appended to the response directly, exposing BearerToken
    response.Clusters = projectClusters
    // ...
}

// Patched Implementation Pattern
func (s *Server) GetDetailedProject(...) {
    // ... authorization checks ...
    projectClusters, err := s.db.GetProjectClusters(ctx, projectName)
    sanitizedClusters := make([]appv1.Cluster, 0)
    for _, c := range projectClusters {
        // The Sanitized() method strips credentials before serialization
        sanitizedClusters = append(sanitizedClusters, *c.Sanitized())
    }
    response.Clusters = sanitizedClusters
    // ...
}

The Sanitized() method for the Cluster struct explicitly acts as an allowlist. It creates a new object and copies over only non-sensitive fields such as Server, Name, and Namespaces. The entire ClusterConfig struct, which houses the sensitive operational tokens, is intentionally omitted from the sanitized struct. This completely mitigates the data leak by severing the data flow from the internal struct to the external API response.

Exploitation of CVE-2025-55190 requires an attacker to possess a valid authentication token for the Argo CD instance. This token must have at least projects, get permission for one or more projects. The attacker does not need administrative privileges or explicit secrets-access permissions.

The attack sequence begins with the attacker generating or intercepting a valid JSON Web Token (JWT) via the /api/v1/session endpoint. Once authenticated, the attacker issues an HTTP GET request to the /api/v1/projects/{project_name}/detailed API route using the compromised or low-privileged token.

The server processes the request and returns a 200 OK response containing a JSON payload. The attacker parses this JSON response and extracts the repositories and clusters arrays. Within these arrays, the attacker searches for the username, password, and bearerToken keys, which contain the exposed plain-text credentials.

The impact of CVE-2025-55190 is classified as critical, as it breaks the isolation boundaries between application developers and infrastructure operators. By exposing BearerToken and Password fields, the vulnerability provides attackers with the exact credentials used by Argo CD to manage external systems.

If an attacker extracts a Kubernetes cluster bearer token, they can authenticate directly to the target cluster's API server. Depending on the privileges assigned to the Argo CD service account in that cluster, the attacker may gain administrative control over the cluster, allowing for arbitrary workload deployment, data exfiltration, or lateral movement across the infrastructure.

Similarly, exposed Git repository credentials allow the attacker to access private source code, infrastructure-as-code (IaC) definitions, and potentially inject malicious commits. This leads directly to supply chain attacks, where compromised configurations are automatically deployed by Argo CD or other continuous integration systems.

The CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H accurately reflects this environment-spanning risk. The Scope is Changed (S:C) because the vulnerability in Argo CD directly facilitates the compromise of distinct external entities, namely the managed Kubernetes clusters and upstream Git repositories.

To address CVE-2025-55190, administrators must upgrade all Argo CD instances to a patched version immediately. The maintained release branches have been updated to versions 2.13.9, 2.14.16, 3.0.14, and 3.1.2. These versions implement the explicit object sanitization required to protect sensitive fields during API serialization.

Patching the software is only the first phase of remediation. Because the vulnerability allows silent credential extraction without generating specialized audit logs for secret access, administrators must operate under the assumption that all project-scoped repository and cluster credentials stored in vulnerable Argo CD instances have been compromised.

Following the upgrade, organizations must systematically rotate all affected secrets. This includes regenerating Kubernetes service account bearer tokens, resetting Git service account passwords, and replacing any associated SSH private keys used for repository authentication.

As an ongoing defense-in-depth measure, security teams should audit Argo CD RBAC configurations. The principle of least privilege must be strictly enforced, ensuring that standard application developers only hold projects, get permissions for the specific projects they actively manage, thereby minimizing the potential blast radius of compromised developer accounts.