Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-71208

CVE-2026-71208: KubeSphere Cluster Controller SSRF Vulnerability

CVE-2026-71208 is a server-side request forgery flaw in KubeSphere's cluster-controller that allows attackers to force outbound requests to internal endpoints. This article covers technical details, impact, and mitigations.

Published:

CVE-2026-71208 Overview

CVE-2026-71208 is a Server-Side Request Forgery (SSRF) vulnerability in KubeSphere's cluster-controller reconciliation logic. The flaw resides in pkg/utils/clusterclient/clusterclient.go, specifically the addCluster function. The controller processes every Cluster custom resource's connection configuration and calls Discovery().ServerVersion() against the CRD-specified Kubernetes API endpoint. KubeSphere parses the endpoint URL using url.Parse with no allow-list or deny-list for loopback, RFC1918 private ranges, link-local, or cloud-metadata addresses such as 169.254.169.254. Authenticated users who can create or update a Cluster CRD can force controller-manager and apiserver pods to issue outbound requests to arbitrary internal or metadata endpoints. This maps to CWE-918: Server-Side Request Forgery.

Critical Impact

An authenticated tenant can pivot from Cluster CRD write access to reading cloud instance metadata credentials and probing internal services reachable from KubeSphere control-plane pods.

Affected Products

  • KubeSphere cluster-controller component
  • pkg/utils/clusterclient/clusterclient.go (addCluster reconciliation path)
  • KubeSphere multi-cluster deployments accepting Cluster custom resources

Discovery Timeline

  • 2026-08-05 - CVE-2026-71208 published to NVD
  • 2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-71208

Vulnerability Analysis

KubeSphere manages federated Kubernetes clusters through a Cluster custom resource definition. The connection configuration inside each Cluster CRD contains a kubeconfig referencing a remote API server URL. During reconciliation, addCluster constructs a client and immediately probes the endpoint by calling Discovery().ServerVersion(). The endpoint value is validated only for URL syntax. No network policy layer sits between the parser and the HTTP client. As a result, any host reachable from the controller-manager pod becomes a valid target, including cluster-internal services and cloud metadata IPs.

Exploitation succeeds because the outbound request originates from a workload that typically holds a service account token and pod network access. Cloud metadata endpoints on AWS, GCP, and Azure return short-lived credentials to callers on the instance network. The attacker does not need to read the HTTP response body directly. Timing, error messages, and controller logs can leak enough information to confirm the request was issued and to characterize responses. See the SSRF exploitation write-up for the reported technique.

Root Cause

The root cause is missing egress validation. The addCluster function trusts URL syntax as a security boundary. No filter rejects 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, or fd00::/8. The reconciler runs synchronously on every CRD change, so a single malicious update triggers an immediate outbound request.

Attack Vector

An authenticated user with RBAC permissions to create or update Cluster CRDs submits a Cluster object whose spec.connection.kubernetesAPIEndpoint points to an internal target such as http://169.254.169.254/latest/meta-data/iam/security-credentials/. The controller-manager reconciles the object and issues the discovery request from within the KubeSphere control-plane namespace. The attacker observes controller behavior, logs, or downstream state to infer the response.

See the KubeSphere repository for the affected reconciliation code and the public SSRF report for reproduction details.

Detection Methods for CVE-2026-71208

Indicators of Compromise

  • Cluster CRDs whose spec.connection.kubernetesAPIEndpoint resolves to loopback, RFC1918, link-local, or cloud-metadata addresses.
  • Egress connections from KubeSphere controller-manager or apiserver pods to 169.254.169.254, metadata.google.internal, or 169.254.170.2.
  • Discovery API errors in ks-controller-manager logs referencing unexpected hosts or private ranges.

Detection Strategies

  • Audit Cluster CRD create and update events through Kubernetes audit logs, filtering on resource=clusters.cluster.kubesphere.io.
  • Inspect controller-manager egress traffic with a CNI or service-mesh flow log and alert on destinations outside the expected member-cluster IP set.
  • Correlate CRD write events with outbound flows within a short time window to attribute SSRF attempts to specific service accounts.

Monitoring Recommendations

  • Ship Kubernetes audit logs and CNI flow logs to a centralized analytics platform for correlation.
  • Alert on any controller-manager pod contacting cloud metadata IPs, which should never occur in normal operation.
  • Track RBAC subjects granted create or update verbs on clusters.cluster.kubesphere.io and review the list on a regular cadence.

How to Mitigate CVE-2026-71208

Immediate Actions Required

  • Restrict RBAC so only trusted platform administrators can create or update Cluster CRDs.
  • Apply a Kubernetes NetworkPolicy to the KubeSphere control-plane namespace that denies egress to loopback, RFC1918, and link-local ranges except approved member-cluster endpoints.
  • Enforce IMDSv2 with hop-limit 1 on AWS nodes and equivalent metadata protections on GCP and Azure to blunt credential theft.

Patch Information

No vendor patch identifier is listed in the NVD entry for CVE-2026-71208 at publication. Track the KubeSphere repository for upstream fixes to pkg/utils/clusterclient/clusterclient.go and upgrade once a release addresses the missing endpoint validation.

Workarounds

  • Deploy an admission controller (OPA Gatekeeper or Kyverno) that rejects Cluster CRDs whose endpoint host resolves to private, loopback, or metadata addresses.
  • Route controller-manager egress through an HTTP proxy that enforces an allow-list of known member-cluster API servers.
  • Remove Cluster CRD write permissions from tenant roles until admission-time validation is in place.
bash
# Example NetworkPolicy denying metadata and private-range egress from ks-controller-manager
cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-internal-egress
  namespace: kubesphere-system
spec:
  podSelector:
    matchLabels:
      app: ks-controller-manager
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 127.0.0.0/8
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16
        - 169.254.0.0/16
EOF

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.