CVE-2025-26521
📋 TL;DR
This vulnerability in Apache CloudStack allows project members with access to CKS-based Kubernetes clusters to steal the API and secret keys of the cluster creator's 'kubeadmin' account. Attackers can then impersonate the creator to perform privileged actions, potentially compromising all resources under that account. Only users of Apache CloudStack with CKS-based Kubernetes clusters in projects are affected.
💻 Affected Systems
- Apache CloudStack
📦 What is this software?
⚠️ Risk & Real-World Impact
Worst Case
Complete compromise of the creator's account leading to unauthorized access, data exfiltration, resource destruction, and lateral movement across the CloudStack environment.
Likely Case
Project members with malicious intent or compromised accounts gaining elevated privileges to manipulate Kubernetes clusters and associated cloud resources.
If Mitigated
Limited to authorized project members only, but still represents an excessive privilege escalation within project boundaries.
🎯 Exploit Status
Exploitation requires project membership and access to Kubernetes clusters, but the actual attack involves simple API calls to retrieve credentials from the cluster secret.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 4.19.3.0 or 4.20.1.0
Vendor Advisory: https://cloudstack.apache.org/blog/cve-advisories-4.19.3.0-4.20.1.0/
Restart Required: Yes
Instructions:
1. Upgrade Apache CloudStack to version 4.19.3.0 or 4.20.1.0. 2. Restart CloudStack management server. 3. For existing clusters, follow the service account migration steps in the advisory.
🔧 Temporary Workarounds
Service Account Migration
linuxCreate dedicated service accounts for Kubernetes clusters to isolate credentials from user accounts.
Create service account with 'Project Kubernetes Service Role'
Add to project
Generate API/secret keys
Update cloudstack-secret in kube-system namespace
Regenerate original user's keys
🧯 If You Can't Patch
- Implement strict project membership controls and audit all project members regularly
- Monitor Kubernetes cluster access logs for suspicious secret retrieval activities
🔍 How to Verify
Check if Vulnerable:
Check if CloudStack version is below 4.19.3.0 or 4.20.1.0 and if CKS-based Kubernetes clusters exist in projects.Check Version:
Check CloudStack management server version via API or configuration filesVerify Fix Applied:
Verify CloudStack version is 4.19.3.0 or higher, and that Kubernetes clusters use service account credentials instead of user account credentials in cloudstack-secret.📡 Detection & Monitoring
Log Indicators:
- Unauthorized access to cloudstack-secret in Kubernetes clusters
- API calls from unexpected accounts performing privileged operations
- Multiple failed authentication attempts followed by successful privileged actions
Network Indicators:
- Unusual API traffic patterns from Kubernetes clusters to CloudStack management server
- Credential harvesting attempts from cluster secrets
SIEM Query:
Search for 'cloudstack-secret' access in Kubernetes audit logs combined with privileged CloudStack API calls from new or unexpected sources