KubeSphere CVE-2026-71208

The attacker must hold Kubernetes RBAC permissions granting 'create' or 'update' verbs on the clusters resource in the cluster.kubesphere.io API group - this is a low-privilege but non-default permission that must be deliberately assigned via a ClusterRole or Role binding, not simply being an authenticated Kubernetes user. The KubeSphere multi-cluster management feature must be active and the cluster-controller reconciliation loop must be running; single-cluster deployments without this component are not exposed through this specific code path. Exploitation is fully automated once the malicious Cluster CRD is submitted - no administrator review or interaction is required before the controller-manager issues the SSRF request. The highest-impact exploitation path (cloud credential theft) additionally requires the controller-manager pods to be scheduled on nodes where the cloud provider IMDS at 169.254.169.254 is reachable from the pod network, which is the default on AWS, GCP, and Azure unless IMDS access is explicitly blocked at the hypervisor or via IMDSv2 enforcement. On-premises or air-gapped deployments still face SSRF against internal RFC1918 services reachable from the controller-manager pod's network position.

The NVD-assigned CVSS 3.1 score of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) correctly reflects the low-privilege prerequisite and high confidentiality impact, but the S:U (Unchanged scope) assignment likely understates real-world impact. SSRF against cloud instance metadata services constitutes a scope change: the affected resource - IAM credentials, instance identity, user-data scripts from IMDS - lies entirely outside the Kubernetes cluster's security authority. An S:C assessment yields a base score of approximately 8.5. No EPSS data was provided in the intelligence feed, which is a gap; without it, probabilistic exploitation likelihood cannot be quantified from available signals. CISA KEV is absent, meaning active in-the-wild exploitation has not been independently confirmed. However, a public researcher write-up exists, reducing the skill barrier for exploitation significantly. Real-world priority should be rated HIGH for any KubeSphere deployment on AWS, GCP, or Azure infrastructure where IMDS is reachable from the pod network: successful SSRF to 169.254.169.254 can return short-lived but high-privilege cloud IAM credentials, enabling full cloud account takeover as a secondary step entirely outside the Kubernetes blast radius. On-premises deployments face SSRF against internal services but cannot reach cloud IMDS, reducing but not eliminating risk.

A developer or tenant holding a namespace-scoped role that includes 'create' on clusters.cluster.kubesphere.io submits a crafted Cluster CRD with the connection API server URL set to http://169.254.169.254/latest/meta-data/iam/security-credentials/my-ec2-role. The KubeSphere controller-manager's reconciliation loop immediately issues an HTTP GET to that address via Discovery().ServerVersion(), and - because the pod runs on an EC2 node with an attached IAM role - the IMDS returns a JSON credential blob containing an access key, secret key, and session token. A public researcher write-up at https://github.com/ashikmd7/kubeSphere/blob/main/SSRF%20via%20Cluster%20CRD%20KubeConfig/README.md demonstrates this technique, substantially lowering the bar for exploitation.