EUVD-2026-53205
GHSA-w56j-p32j-vmh4
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
S:C chosen over NVD's S:U because SSRF pivots to cloud IMDS and internal hosts outside the cluster's security authority; all other metrics align with the NVD vector.
Primary rating from Vendor (TuranSec).
CVSS VectorVendor: TuranSec
Lifecycle Timeline
4DescriptionCVE.org
KubeSphere's cluster-controller reconciliation (pkg/utils/clusterclient/clusterclient.go, addCluster) processes every Cluster custom resource's connection configuration and immediately calls Discovery().ServerVersion() against the CRD-specified Kubernetes API endpoint, which is parsed only for URL syntax (url.Parse) with no allow/deny-list for loopback, RFC1918 private ranges, link-local, or cloud-metadata addresses (e.g. 169.254.169.254). A user able to create or update a Cluster CRD can force the controller-manager and apiserver pods to issue outbound requests to arbitrary internal or metadata endpoints.
AnalysisAI
Server-Side Request Forgery in KubeSphere's multi-cluster controller allows any low-privileged user with Cluster CRD create or update permissions to weaponize the controller-manager and apiserver pods as HTTP proxies against arbitrary internal addresses, RFC1918 networks, and cloud instance metadata services including AWS IMDS at 169.254.169.254. The flaw resides in pkg/utils/clusterclient/clusterclient.go (addCluster), where the CRD-specified Kubernetes API endpoint undergoes only Go url.Parse() syntax validation before Discovery().ServerVersion() is called - no loopback, private-range, link-local, or metadata-address filtering is applied. A public researcher write-up demonstrating the attack path exists; no active exploitation has been confirmed in CISA KEV at time of analysis.
Technical ContextAI
KubeSphere extends Kubernetes with a Cluster custom resource definition (CRD) to manage federated multi-cluster topologies. Its cluster-controller reconciliation loop processes every Cluster CRD object and, in the addCluster function of pkg/utils/clusterclient/clusterclient.go, reads the .spec.connection field containing the target API server URL and kubeconfig, then immediately invokes client-go's Discovery().ServerVersion() HTTP GET against that URL. URL validation is limited to Go's stdlib url.Parse(), which only checks syntactic correctness and does not validate the destination host against any allowlist of trusted Kubernetes API server addresses or any blocklist for loopback (127.0.0.1/::1), RFC1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local (169.254.0.0/16), or cloud-metadata addresses. CWE-918 (Server-Side Request Forgery) precisely characterizes this root cause: the server accepts a URL from an untrusted source and fetches it without enforcing a destination trust boundary, making the controller-manager pod an unintended HTTP proxy. The CPE cpe:2.3:a:kubesphere:kubesphere:*:*:*:*:*:*:*:* indicates all tracked KubeSphere versions are affected.
RemediationAI
No vendor-released patch with an explicit fixed version has been identified at time of analysis. Administrators should monitor the upstream repository at https://github.com/kubesphere/kubesphere for commits addressing SSRF in pkg/utils/clusterclient/clusterclient.go and apply a patched release once available. As an immediate compensating control, restrict Kubernetes RBAC so that only cluster-admin-equivalent roles can create or update Cluster CRDs (clusters.cluster.kubesphere.io); removing 'create' and 'update' verbs on this resource from tenant or developer roles eliminates the PR:L attack surface entirely, limiting exploitation to actors who are already highly privileged. For cloud-hosted deployments, enforce IMDSv2 (Instance Metadata Service v2) on all nodes - this requires a session-oriented PUT request before any GET to the metadata endpoint, blocking naive HTTP-level SSRF probes against 169.254.169.254, though it does not prevent SSRF against other RFC1918 targets. Deploy Kubernetes NetworkPolicy or service-mesh egress rules on the controller-manager pod's namespace to restrict outbound connections to known, trusted Kubernetes API server CIDRs only; this prevents lateral SSRF to internal services but requires accurate enumeration of legitimate destinations and will break multi-cluster functionality if too restrictive. None of these controls address the root cause - the definitive fix is a patched KubeSphere release that implements a destination allowlist or blocklist in addCluster.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today