Apache CloudStack Vulnerability Allows Attackers to Execute Privileged Actions

The Apache CloudStack project is a leading open-source Infrastructure-as-a-Service (IaaS) platform used globally by many organizations to orchestrate cloud environments.

Recently, several critical security vulnerabilities have been uncovered, posing serious risks to organizations relying on CloudStack for their cloud management needs. These issues enable attackers to execute privileged actions, potentially leading to a complete compromise of cloud resources.

Critical and High-Severity Flaws Identified

Recent security advisories from the Apache CloudStack community detail multiple vulnerabilities, some of which are classified as Critical or High severity. The most pressing issues include:

1. Exposed API Keys in CKS Clusters (CVE-2025-26521 and CVE-2025-47713)

The most severe flaw, tracked as CVE-2025-26521, affects the CloudStack Kubernetes Service (CKS). When a user creates a Kubernetes cluster within a project, the API and secret keys of the creator’s account are stored in the Kubernetes secret named cloudstack-secret.

Project members with access to this Kubernetes cluster a relatively common scenario can extract these credentials. Once obtained, attackers can impersonate the creator, potentially gaining full control over not just the Kubernetes cluster but also the underlying CloudStack resources accessible to the original account.

Technical Impact:
This allows a project insider (or compromised user) to escalate privileges, perform privileged operations, and compromise the confidentiality, integrity, and availability of all resources owned by that account. The remediation involves upgrading to CloudStack versions 4.19.3.0 or 4.20.1.0, which implement proper key isolation.

Additional Flaw: Password Reset for Admin Roles (CVE-2025-47713)
A malicious Domain Admin within the ROOT domain can reset passwords of Admin-type user accounts in CloudStack versions up to 4.20.0.0. This privilege escalation vulnerability enables attackers to assume control of higher-privileged accounts, exposing sensitive APIs and cloud resources to unauthorized access.

Other Notable Vulnerabilities

• CVE-2025-30675 – Unauthorized template/ISO access: Domain or Resource Admins can abuse the listTemplates and listIsos APIs to view templates and ISOs across unrelated domains, potentially exposing sensitive configuration data.
• CVE-2025-47849 – Insecure API/Secret Key Access: Domain Admins in the ROOT domain can access API/secret keys of Admin user accounts within the same domain, leading to impersonation and privilege escalation.
• CVE-2025-22829 – Improper privilege management in the Quota plugin: Authenticated users can tamper with quota configuration and email settings for any account.

Technical Remediation and Mitigation Steps

To mitigate these vulnerabilities, administrators are strongly urged to upgrade CloudStack to version 4.19.3.0 or 4.20.1.0. Additionally, specific remediation steps for the CKS cluster key exposure issue are provided below:

Creating and Managing Service Accounts for Kubernetes Clusters

To minimize privilege exposure in CKS clusters, create a dedicated service account for each project hosting Kubernetes clusters:

1. Create a New Service Account
   • Account Name: kubeadmin-<FIRST_EIGHT_CHARACTERS_OF_PROJECT_ID>
   • First Name: Kubernetes
   • Last Name: Service User
   • Account Type: 0 (Normal User)
   • Role ID: <ID_OF_SERVICE_ROLE>
2. Add the Service Account to the Project
   • Assign this account to the relevant project.
3. Generate API and Secret Keys
   • Generate new API and Secret keys for the service account.
4. Update the CloudStack Secret in Kubernetes
   • Create a temporary configuration file:textapi-url = <API_URL> # e.g., <MS_URL>/client/api api-key = <SERVICE_USER_API_KEY> secret-key = <SERVICE_USER_SECRET_KEY> project-id = <PROJECT_ID>
   • Delete the existing secret in your Kubernetes cluster:text./kubectl --kubeconfig kube.conf -n kube-system delete secret cloudstack-secret
   • Create a new secret:text./kubectl --kubeconfig kube.conf -n kube-system create secret generic cloudstack-secret --from-file=/tmp/cloud-config
   • Remove the temporary configuration file:textrm /tmp/cloud-config
5. Regenerate API and Secret Keys for the Original User
   • Generate new keys for the original user account used to create the Kubernetes cluster.

Security Enhancements in Fixed Versions

CloudStack versions 4.19.3.0 and 4.20.1.0 introduce stricter role and privilege validations:

• Role Type Hierarchy Validation: Only users with equal or higher privileges can perform sensitive operations.
• API Privilege Comparison: Callers must possess all privileges of the user they are operating on.
• New Domain-level Settings:
  • role.types.allowed.for.operations.on.accounts.of.same.role.type
    • Defines which role types can act on users of the same role type.
    • Default: “Admin, DomainAdmin, ResourceAdmin”
  • allow.operations.on.users.in.same.account
    • Controls user operations within the same account.
    • Default: true

Affected Versions and Credits

• CVE-2025-26521: CloudStack 4.17.0.0 through 4.19.2.0, 4.20.0.0 (users should skip 4.20.0.0)
• CVE-2025-30675: CloudStack 4.0.0 through 4.19.2.0, 4.20.0.0
• CVE-2025-47713, CVE-2025-47849: CloudStack 4.10.0.0 through 4.19.2.0, 4.20.0.0
• CVE-2025-22829: CloudStack 4.20.0.0 (Quota plugin only)

Credits:
The discoveries are credited to security researchers including Wei Zhou, Bernardo De Marco Gonçalves, Scott Schmitz, Kevin, and Fabricio Duarte.

Organizations using Apache CloudStack should prioritize upgrading to version 4.19.3.0 or 4.20.1.0 immediately. The outlined technical steps will help secure Kubernetes clusters and prevent privilege escalation attacks.

Continuous monitoring and adherence to least-privilege principles are crucial for maintaining the security of cloud environments. The community is urged to apply these fixes and share information about potential exploitation attempts with the Apache CloudStack security team.