KubeSphere’s cluster-controller reconciliation processes each Cluster custom resource’s connection configuration and immediately invokes Discovery.ServerVersion against the endpoint specified in the CRD. Only URL syntax is validated; there is no whitelist or blacklist for loopback, RFC1918 private ranges, link‑local ranges, or cloud‑metadata addresses such as 169.254.169.254. This allows an attacker who can create or modify a Cluster CRD to force the controller‑manager pods to send requests to any HTTP endpoint, including internal or infrastructure services, potentially exposing confidential data or internal networks.

All KubeSphere deployments that use the cluster‑controller reconciliation component are affected. No specific product or version exclusions were noted in the advisory, implying that the issue may be present across all released versions until the vendor ships a fix. Any user with permission to create or update a Cluster CRD can trigger the SSRF behavior.

The CVSS score of 6.5 places the vulnerability in the medium severity range. The EPSS score of <1% indicates a very low but non‑zero exploitation probability, and the vulnerability is not yet listed in CISA’s KEV catalog, suggesting it has not been exploited in the wild. However, the requirement to modify a Cluster CRD means that the attacker must have cluster‑level privileges; the attack therefore represents an internal privilege escalation rather than an external remote exploit. Privileged controller‑manager pods can probe any reachable internal address, including cloud‑metadata endpoints, compromising confidentiality and integrity of internal services.