Miggo Logo

CVE-2025-62714: Karmada Dashboard API Unauthorized Access Vulnerability

N/A

CVSS Score

Basic Information

EPSS Score
-
Published
10/24/2025
Updated
10/24/2025
KEV Status
No
Technology
TechnologyGo

Technical Details

CVSS Vector
-
Package NameEcosystemVulnerable VersionsFirst Patched Version
github.com/karmada-io/dashboardgo< 0.2.00.2.0

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability, GHSA-5qjg-9mjh-4r92, is an authentication bypass in the Karmada Dashboard API. My analysis of the provided patches confirms that the root cause was the complete absence of an authentication and authorization enforcement mechanism for the API endpoints under the /api/v1 path.

The primary fix was introduced in commit 1b3672eff4994dbe61cbb7cccaabd665a2d33ec5, which created a new AuthMiddleware. This middleware, applied in cmd/api/app/router/setup.go, ensures that every request to a v1 API endpoint has a valid Authorization token. Before this change, any function handling a route under /api/v1 was effectively public.

Furthermore, the handler functions themselves were using privileged in-cluster clients (e.g., client.InClusterKarmadaClient()) to interact with the Kubernetes and Karmada APIs. This meant that an unauthenticated request would be processed with the full permissions of the Karmada Dashboard's service account. The patches in commit a7defcd475486122eca5cfe18110b423a3c53851 refactored all API handlers to retrieve the API client from the request context, which is populated by the new ClientMiddleware using the credentials from the authenticated user's request. This ensures that even authenticated users can only perform actions they are authorized to.

The vulnerability description explicitly mentions endpoints like /api/v1/secret and /api/v1/service, which are handled by functions like handleGetSecrets and handleGetServices. These, along with numerous other handlers for different resource types (deployments, jobs, policies, etc.), were all vulnerable due to the missing middleware. Any of these function names would appear in a runtime profile during exploitation. The generateAPIProxy function was also patched to enforce authentication for proxied requests.

In summary, the identified vulnerable functions are the API handlers that, prior to the patch, were processing unauthenticated requests using privileged clients. The evidence is the widespread replacement of privileged client creation with context-aware client retrieval, enabled by the new authentication middleware.

Vulnerable functions

handleGetSecrets
cmd/api/app/routes/secret/handler.go
This function, which handles requests to list secrets, was exposed without authentication. An attacker could directly call the `/api/v1/secrets` endpoint to retrieve all secrets from the Karmada control plane's Kubernetes cluster, as the function previously used a privileged in-cluster client by default.
handleGetServices
cmd/api/app/routes/service/handler.go
This function, which handles requests to list services, was exposed without authentication. An attacker could directly call the `/api/v1/service` endpoint to list all services, gaining sensitive network information. The vulnerability existed because the endpoint lacked an authentication check and the handler used a privileged in-cluster client.
handleGetClusterList
cmd/api/app/routes/cluster/handler.go
This function lists all member clusters managed by Karmada. It was unprotected, allowing an unauthenticated attacker to enumerate all connected clusters, which could be a precursor to further attacks.
generateAPIProxy
cmd/web/app/web.go
This function serves as a reverse proxy for API requests. Prior to the patch, it did not validate the `Authorization` header, allowing unauthenticated requests to be forwarded to backend API services. This effectively created an authentication bypass for any API endpoint accessed through this proxy.
AuthMiddleware
cmd/api/app/router/middleware.go
This function was created as the primary fix for the vulnerability. Its purpose is to check for an `Authorization` token in the request header or query parameters. Before this middleware was introduced and applied to the `/api/v1` route group, all API endpoints under this path were unprotected and accessible without authentication.

WAF Protection Rules

WAF Rule

### Imp**t T*is is *n *ut**nti**tion *yp*ss vuln*r**ility in t** K*rm*** **s**o*r* *PI. T** ***k*n* *PI *n*points (*.*., /*pi/v*/s**r*t, /*pi/v*/s*rvi**) *i* not *n*or** *ut**nti**tion, *llowin* un*ut**nti**t** us*rs to ****ss s*nsitiv* *lust*r in*or

Reasoning

T** vuln*r**ility, **S*-*qj*-*mj*-*r**, is *n *ut**nti**tion *yp*ss in t** K*rm*** **s**o*r* *PI. My *n*lysis o* t** provi*** p*t***s *on*irms t**t t** root **us* w*s t** *ompl*t* **s*n** o* *n *ut**nti**tion *n* *ut*oriz*tion *n*or**m*nt m****nism *