CVE-2025-26521: 
Apache CloudStack vulnerability analysis and mitigation

CVE-2025-26521 is a sensitive information exposure vulnerability in Apache CloudStack's Container Service for Kubernetes (CKS) feature, where API and secret keys of the kubeadmin user are improperly stored in Kubernetes cluster secrets and accessible to unauthorized project members. It affects Apache CloudStack versions 4.17.0.0 through 4.19.2.x and 4.20.0.0 through 4.20.0.x. The vulnerability was published on June 10, 2025, and patches were released in versions 4.19.3.0 and 4.20.1.0. It carries a CVSS v3.1 base score of 8.1 (High) (Red Hat Advisory, Apache CloudStack Advisory).

The root cause is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). When a user creates a CKS-based Kubernetes cluster within a CloudStack project, the platform uses the API key and secret key of the calling user's kubeadmin account to create a Kubernetes secret config inside the cluster. Any project member with access to the CKS-based Kubernetes cluster can read this secret, thereby obtaining the cluster creator's full CloudStack API credentials. The attack requires only low-level authenticated access (project membership) and is exploitable over the network without user interaction (Apache CloudStack Advisory, Red Hat Advisory).

A malicious project member who retrieves the exposed API and secret keys can fully impersonate the cluster creator's kubeadmin account, enabling them to perform any privileged CloudStack API action on behalf of that account. This results in complete compromise of the confidentiality and integrity of all resources owned by the creator's account, including virtual machines, networks, storage, and other cloud assets. While the CVSS score reflects no direct availability impact, the ability to delete or reconfigure resources means availability can be indirectly affected through privileged misuse (Apache CloudStack Advisory, Red Hat Advisory).

1. Gain Project Membership: Obtain membership in a CloudStack project that has a CKS-based Kubernetes cluster, either through legitimate access or social engineering.
2. Access the Kubernetes Cluster: Use existing project credentials to access the CKS-based Kubernetes cluster (e.g., via kubectl with a valid kubeconfig).
3. Read the Kubernetes Secret: Query the Kubernetes secret config created during cluster provisioning — for example, using kubectl get secret <cloudstack-secret-name> -n <namespace> -o yaml — to retrieve the stored CloudStack API key and secret key of the kubeadmin user.
4. Extract Credentials: Decode the base64-encoded values from the secret to obtain the plaintext API key and secret key of the cluster creator's kubeadmin account.
5. Impersonate the Creator: Use the extracted API key and secret key to authenticate to the CloudStack API as the kubeadmin user of the creator's account, enabling full privileged access to all resources owned by that account (Apache CloudStack Advisory).

• Logs: Unexpected CloudStack API calls authenticated with the kubeadmin API key from IP addresses not associated with the cluster creator or automation systems; audit log entries showing privileged actions (VM deletion, network changes) performed by kubeadmin outside of normal operational windows.
• Kubernetes: Access logs on the Kubernetes API server showing reads of the CloudStack secret object by accounts other than the cluster provisioner or expected service accounts.
• Network: CloudStack management API requests originating from unusual source IPs using credentials associated with the kubeadmin account.
• CloudStack Audit: API usage reports showing the kubeadmin account performing actions inconsistent with its expected role (e.g., accessing resources in other projects or accounts).

Upgrade Apache CloudStack to version 4.19.3.0 or 4.20.1.0, which resolves the issue by using a dedicated, limited-privilege service account instead of the creator's personal API keys (Apache CloudStack Advisory). For existing clusters, administrators should: (1) create a new service account with the "Project Kubernetes Service Role" named kubeadmin-<FIRST_EIGHT_CHARACTERS_OF_PROJECT_ID>; (2) add the service account to the project and generate new API/secret keys; (3) update the CloudStack secret inside each affected Kubernetes cluster with the new service account credentials; and (4) regenerate the original kubeadmin user's API and secret keys to invalidate any previously exposed credentials (Apache CloudStack Advisory, Apache Mailing List).

The vulnerability received coverage from several cybersecurity news outlets shortly after disclosure, including GBHackers, CyberPress, and CyberSecurityNews, which highlighted the risk to cloud infrastructure (GBHackers, CyberPress, CyberSecurityNews). The Hacker News included it in their weekly security recap, indicating moderate community interest. ShapeBlue, a major CloudStack contributor, published a security advisory covering the fixes in versions 4.19.3.0 and 4.20.1.0 (ShapeBlue Advisory). No significant controversy or researcher debate has been observed around this vulnerability.