Skip to main content
A Leader in the 2026 Gartner® Magic Quadrant™ for Endpoint Protection. Six years running.Find Out Why
CVE Vulnerability Database
Vulnerability Database/CVE-2025-26521

CVE-2025-26521: Apache CloudStack Privilege Escalation

CVE-2025-26521 is a privilege escalation vulnerability in Apache CloudStack where project members can access API keys of CKS cluster creators, enabling unauthorized privileged actions. This article covers technical details, affected versions, impact assessment, and step-by-step mitigation procedures.

Published:

CVE-2025-26521 Overview

Apache CloudStack contains an information disclosure vulnerability [CWE-200] affecting CloudStack Kubernetes Service (CKS) clusters created within projects. When a user-account creates a CKS-based Kubernetes cluster in a project, the API key and secret key of the kubeadmin user of the caller's account are embedded into the cluster's cloudstack-secret configuration. Any project member who can access the cluster can extract these credentials and impersonate the cluster creator. Apache CloudStack has assigned this issue HIGH severity, and fixes are available in versions 4.19.3.0 and 4.20.1.0.

Critical Impact

A project member with access to the CKS cluster can retrieve the creator's kubeadmin API and secret keys, enabling full impersonation and compromise of confidentiality and integrity of the creator account's resources.

Affected Products

  • Apache CloudStack versions prior to 4.19.3.0 (4.19.x branch)
  • Apache CloudStack versions prior to 4.20.1.0 (4.20.x branch)
  • CloudStack Kubernetes Service (CKS) clusters provisioned in projects

Discovery Timeline

  • 2025-06-10 - CVE-2025-26521 published to the National Vulnerability Database
  • 2025-07-01 - Last updated in NVD database

Technical Details for CVE-2025-26521

Vulnerability Analysis

The issue stems from how Apache CloudStack provisions CKS-based Kubernetes clusters inside a project context. CloudStack injects a Kubernetes secret named cloudstack-secret into the kube-system namespace. This secret holds the CloudStack API URL, API key, and secret key used by in-cluster Kubernetes providers and autoscaling components to call back into CloudStack.

Instead of generating a scoped service account for the project, CloudStack reuses the API key and secret key of the kubeadmin user belonging to the account that created the cluster. Because the cluster is a shared project resource, any project member with read access to the secret can retrieve these credentials.

Once extracted, the credentials grant the attacker the full CloudStack privileges of the creator account. The attacker can invoke CloudStack APIs to manipulate virtual machines, networks, storage, and other resources owned by that account, breaching the tenant isolation model that projects are intended to provide.

Root Cause

The root cause is a credential reuse and over-privileged secret design [CWE-200]. CloudStack should have provisioned a dedicated, least-privilege service account for each project cluster. Instead, it stored the creator's personal kubeadmin API and secret keys inside a shared cluster secret accessible to all project members with Kubernetes access.

Attack Vector

Exploitation requires the attacker to be an authenticated member of a CloudStack project that hosts a CKS-based Kubernetes cluster. The attacker uses standard kubectl access to read the cloudstack-secret resource in the kube-system namespace. After decoding the secret, the attacker recovers the API key and secret key. They can then call the CloudStack API as the cluster creator's kubeadmin user and perform any action that user is authorized to perform within the account.

No memory corruption or unauthenticated network access is required. The vulnerability is an authorization and design flaw exposed through normal Kubernetes secret access controls.

No public proof-of-concept exploitation code has been published for this issue. Refer to the Apache CloudStack CVE Advisory and the ShapeBlue Security Advisory for vendor technical details.

Detection Methods for CVE-2025-26521

Indicators of Compromise

  • Reads or kubectl get secret cloudstack-secret -n kube-system -o yaml invocations from project members who are not the cluster owner.
  • CloudStack API calls authenticated with a kubeadmin user originating from IP addresses or user agents outside the expected CKS management plane.
  • Unexpected resource modifications (VM start/stop, snapshot creation, key rotation) performed by the creator's account during periods of user inactivity.

Detection Strategies

  • Audit CloudStack API logs for calls signed with kubeadmin API keys that target resources unrelated to Kubernetes cluster lifecycle operations.
  • Inspect Kubernetes audit logs in each CKS cluster for get and list operations against secrets in the kube-system namespace by project member service accounts.
  • Correlate CloudStack management server logs with project membership changes to identify principals who could have accessed cloudstack-secret.

Monitoring Recommendations

  • Enable Kubernetes audit logging at the Metadata level or higher for all CKS clusters and forward logs to a centralized SIEM.
  • Alert on any CloudStack API key usage originating from a network range that is not the expected Kubernetes worker subnet.
  • Track creation, deletion, and rotation of API keys belonging to kubeadmin users across all accounts.

How to Mitigate CVE-2025-26521

Immediate Actions Required

  • Upgrade Apache CloudStack to version 4.19.3.0 or 4.20.1.0 as soon as possible.
  • Rotate the API key and secret key of every kubeadmin user whose credentials may have been embedded in an existing CKS cluster secret.
  • Audit existing project-based CKS clusters and identify which user accounts were used to create them.
  • Inventory project members with kubectl access to determine the population that could have extracted the credentials.

Patch Information

Apache CloudStack has released fixed versions 4.19.3.0 and 4.20.1.0. Operators should follow the post-upgrade remediation procedure in the Apache CloudStack CVE Advisory: create a new service account named kubeadmin-<FIRST_EIGHT_CHARACTERS_OF_PROJECT_ID> assigned the Project Kubernetes Service Role, add it to the project, generate dedicated API and secret keys, replace the cloudstack-secret inside each Kubernetes cluster, and then regenerate the API and secret keys of the original creator account.

Workarounds

  • For each project hosting a CKS cluster, create a dedicated service account using the Project Kubernetes Service Role and use its keys in the cluster cloudstack-secret.
  • Replace the existing cloudstack-secret in the kube-system namespace with one populated from the service account's API key, secret key, and project-id.
  • After replacing the secret, regenerate the API and secret keys of the original user that created the cluster to invalidate any previously exposed credentials.
  • Restrict project membership for clusters containing legacy secrets until the rotation procedure has been completed.
bash
# Replace the cloudstack-secret with service-account-scoped credentials
cat <<EOF > /tmp/cloud-config
api-url = <MS_URL>/client/api
api-key = <SERVICE_USER_API_KEY>
secret-key = <SERVICE_USER_SECRET_KEY>
project-id = <PROJECT_ID>
EOF

./kubectl --kubeconfig kube.conf -n kube-system delete secret cloudstack-secret
./kubectl --kubeconfig kube.conf -n kube-system \
  create secret generic cloudstack-secret --from-file=/tmp/cloud-config

rm /tmp/cloud-config

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.

Try SentinelOne