KubeSphere 3.4.0 - Insecure Direct Object Reference (IDOR)

KubeSphere 3.4.0 — Insecure Direct Object Reference (IDOR) (CVE-2024-46528)

Summary

KubeSphere versions prior to the fixed releases (see affected versions below) contain an Insecure Direct Object Reference (IDOR) vulnerability that allows a user with minimal platform privileges — for example a "platform-regular" account not joined to any workspace — to access cluster-scoped information and resources that should require workspace or cluster membership. The issue results from insufficient authorization checks when resolving resource requests that include direct identifiers (cluster, node, project, kubeconfig, etc.).

Why this matters

IDORs allow attackers or misconfigured users to escalate information access by directly requesting resources using identifiers (IDs, names or endpoints). In a Kubernetes/KubeSphere context this means sensitive cluster metadata, node listings, project lists, user accounts and in some cases kubeconfig or other configuration artifacts can be leaked. Even if direct control is not immediately possible, exposed metadata can be used for reconnaissance and to craft further attacks.

Technical root cause

• Authorization checks were not consistently enforced for certain API routes and UI endpoints. The server accepted requests for cluster-scoped resources without validating workspace membership or user permissions for the target cluster/namespace.
• Endpoints were implemented to accept direct identifiers (e.g., /clusters/{cluster}/nodes) but did not consult the calling user’s effective permissions or workspace binding before returning data.
• Insufficient separation of concern between authentication (who you are) and authorization (what you are allowed to see) on those API paths.

Affected versions

Product	Affected versions	Fixed in
KubeSphere	≥ 3.0.0 < 3.4.1	3.4.1+
KubeSphere	≥ 4.0.0 < 4.1.3	4.1.3+

CVE and references

• CVE Identifier: CVE-2024-46528
• Vendor: KubeSphere — https://kubesphere.io
• Source code: https://github.com/kubesphere/kubesphere
• Researcher: Okan Kurtulus (public report)

Impact and real-world risks

• Information disclosure: cluster overview, nodes, projects, and user lists can be exposed to unprivileged users.
• Reconnaissance: leaked details help an attacker map infrastructure, identify software versions, and locate high-value targets.
• Privilege escalation potential: if kubeconfig or admin-level artifacts are exposed, attackers could gain control over Kubernetes clusters.
• Compliance & privacy: unauthorized exposure of sensitive data or account lists may violate internal policies or regulations.

High-level proof-of-concept (non-actionable summary)

A low-privileged user account that has not been added to any workspace was able to authenticate to the KubeSphere console and then successfully access several cluster-scoped endpoints (for example cluster overview, node listing, project listing and kubeconfig endpoints) that should have been restricted. The root cause was missing or bypassed checks that verify workspace membership or explicit permission for the target cluster.

Safe verification (for defenders)

Administrators and security teams can safely verify whether their KubeSphere instance is affected by attempting read-only queries using a deliberately limited test account. Use placeholder tokens and keep tests non-destructive (HTTP GET only). Replace TOKEN with the test user's bearer token and HOST with your console address.

curl -s -k -H "Authorization: Bearer TOKEN" \
  "https://HOST:PORT/clusters/default/nodes" | jq .

Explanation: This command issues a read-only GET to the nodes listing for the cluster named "default" while authenticating as a low-privileged user. If the instance is vulnerable, the call will return node metadata. Use HTTPS and the correct port for your deployment; do not use an account with elevated privileges when testing.

Detecting exploitation (logs & monitoring)

Look for patterns in access logs where accounts with limited roles or accounts that are not members of a workspace receive 2xx responses for cluster-scoped endpoints. Correlate access tokens or user IDs with workspace membership records.

# Example ElasticSearch / Kibana query (pseudo-syntax)
event.dataset: "http_access" AND
http.request.method: "GET" AND
http.request.uri.path: "/clusters/*" AND
user.role: "platform-regular" AND
http.response.status_code: 200

Explanation: This sample query filters HTTP access logs for successful GETs to cluster paths initiated by the "platform-regular" role. Adjust field names for your logging schema. Any positive matches should be treated as suspicious and investigated.

Immediate mitigations (if you cannot patch right away)

• Network-level restrictions: Restrict access to KubeSphere console and API ports to trusted networks or via VPN/SSH bastions.
• Ingress/Proxy authentication: Place a fronting reverse proxy or API gateway requiring additional authentication / IP allowlist before traffic reaches KubeSphere.
• Restrict platform roles: Reduce privileges of ambiguous roles (e.g., platform-regular) and ensure no user without workspace membership has read access to cluster-scoped APIs.
• Enable and review audit logs: Turn on KubeSphere and Kubernetes audit logging to capture suspicious read operations and token usage.
• Rotate credentials: Rotate bearer tokens and service account tokens if you suspect unauthorized reads occurred.

Recommended permanent fixes

• Upgrade KubeSphere to a fixed release: 3.4.1+ or 4.1.3+. Follow vendor upgrade instructions and test in staging first.
• Ensure authorization middleware: Verify that all API routes enforce workspace and cluster membership checks; add unit/integration tests to cover access control logic.
• Harden RBAC: Adopt the principle of least privilege across platform roles; be explicit about cluster-scoped vs workspace-scoped permissions.
• Implement defense-in-depth: Use network segmentation, API gateways, and strong authentication to reduce the blast radius of any single product bug.

Recommended policy & operational changes

• Periodic access reviews: Regularly review which users have platform-level or cluster-level access, remove unused accounts.
• Automated scans: Integrate static analysis and API fuzzing during CI to detect missing authorization checks early.
• Incident response playbook: Prepare procedures to detect, contain, and remediate information exposure and to rotate credentials quickly.
• Least-privilege defaults: New roles or user templates should default to deny-list rather than allow-list for cluster-scoped endpoints.

Example SIEM signature (Splunk-like) to alert on unexpected cluster-scoped access

index=web_logs source=kubesphere_access
| where http_method="GET" AND like(uri_path, "/clusters/%")
| lookup user_workspace_lookup user as username OUTPUT workspace
| where isnull(workspace)
| stats count by username, uri_path, status
| where count > 0

Explanation: This query selects GET requests to cluster paths, filters to users who are not associated with any workspace (using a lookup table), and raises results. Adjust the lookup/field names to match your environment. Any positive hits indicate an account without workspace membership successfully requesting cluster-scoped resources.

Responsible disclosure & timeline

• Vulnerability reported by: Okan Kurtulus (public disclosure details available with CVE).
• Vendor: KubeSphere — coordianted fixes released in subsequent maintenance releases (see "Fixed in" table above).
• Action recommended: Apply vendor patches as soon as possible; follow mitigations if immediate patching is not possible.

Further reading & references

• KubeSphere official site: https://kubesphere.io
• KubeSphere GitHub repository: https://github.com/kubesphere/kubesphere
• CVE entry: CVE-2024-46528

Conclusion — practical next steps

• Inventory: Identify all KubeSphere deployments and their versions.
• Patch: Prioritize upgrades to fixed releases (3.4.1+, 4.1.3+).
• Harden: Apply network restrictions and review RBAC to minimize exposure surface.
• Detect: Implement logging/alerting to surface anomalous access to cluster-scoped endpoints.