The flaw allows anyone who can create or modify a Cluster Custom Resource Definition to force KubeSphere’s controller‑manager pods to query any Kubernetes API endpoint specified in the CRD. The controller parses only the URL syntax, with no whitelist or blacklist for loopback addresses, RFC1918 private ranges, link‑local ranges, or cloud‑metadata services such as 169.254.169.254. This results in a server‑side request forgery that can reach internal or infrastructure‑level endpoints, potentially leaking sensitive data or giving the attacker additional attack surface within the cluster.

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 7.1 places the vulnerability in the medium‑to‑high severity range. EPSS data is not currently available, 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.