Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NSummary
CVE-2025-26521 is a high-severity Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) vulnerability in Apache Cloudstack. Its CVSS base score is 8.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Token Impersonation/Theft (T1134.001); ranked at the 46th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and AC-4 (Information Flow Enforcement) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-18065
Vulnerability Data
When an Apache CloudStack user-account creates a CKS-based Kubernetes cluster in a project, the API key and the secret key of the 'kubeadmin' user of the caller account are used to create the secret config in the CKS-based Kubernetes cluster.…
more
A member of the project who can access the CKS-based Kubernetes cluster, can also access the API key and secret key of the 'kubeadmin' user of the CKS cluster's creator's account. An attacker who's a member of the project can exploit this to impersonate and perform privileged actions that can result in complete compromise of the confidentiality, integrity, and availability of resources owned by the creator's account. CKS users are recommended to upgrade to version 4.19.3.0 or 4.20.1.0, which fixes this issue.Updating Existing Kubernetes Clusters in ProjectsA service account should be created for each project to provide limited access specifically for Kubernetes cluster providers and autoscaling. Follow the steps below to create a new service account, update the secret inside the cluster, and regenerate existing API and service keys:1. Create a New Service AccountCreate a new account using the role "Project Kubernetes Service Role" with the following details: 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 ProjectAdd this account to the project where the Kubernetes cluster(s) are hosted. 3. Generate API and Secret KeysGenerate API Key and Secret Key for the default user of this account. 4. Update the CloudStack Secret in the Kubernetes ClusterCreate a temporary file `/tmp/cloud-config` with the following data: api-url = <API_URL> # For example: <MS_URL>/client/api api-key = <SERVICE_USER_API_KEY> secret-key = <SERVICE_USER_SECRET_KEY> project-id = <PROJECT_ID> Delete the existing secret using kubectl and Kubernetes cluster config: ./kubectl --kubeconfig kube.conf -n kube-system delete secret cloudstack-secret Create a new secret using kubectl and Kubernetes cluster config: ./kubectl --kubeconfig kube.conf -n kube-system create secret generic cloudstack-secret --from-file=/tmp/cloud-config Remove the temporary file: rm /tmp/cloud-config5. Regenerate API and Secret KeysRegenerate the API and secret keys for the original user account that was used to create the Kubernetes cluster.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 7 hardening rules · 6 OS baselines
V10.4.9V11.7.1V14.1.2V14.2.4
Mitigating Controls (NIST 800-53 r5) AI
Access enforcement directly stops unauthorized actors from obtaining sensitive information.
Information flow enforcement structurally prevents sensitive data from reaching unauthorized recipients.
Protection of information at rest prevents unauthorized exposure of stored sensitive data.
Transmission confidentiality mechanisms stop exposure of sensitive data on the wire.
Least privilege reduces the set of actors who can reach sensitive information.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.AA-05 directly enforces least-privilege authorization that blocks most unauthorized disclosures, yet CWE-200 also arises from logging, error messages, and side-channel paths that access controls alone do not address.
PR.DS-10 mostly prevents CWE-200 by directly eliminating unauthorized access to sensitive data-in-use, yet only partially addresses the weakness because CWE-200 spans many other exposure vectors outside runtime protection.
PR.IR-01's segmentation/zero-trust controls largely eliminate network-level unauthorized access paths that enable exposure, yet CWE-200 spans many additional vectors (API responses, logs, app logic) that network controls alone cannot close.
Secure SDLC practices catch most exposure flaws via design, testing and release controls, yet CWE-200 spans runtime/config issues a single development outcome cannot fully close.
PR.AA-01 supplies proper credential lifecycle controls that reduce unauthorized access paths, yet leaves many other exposure vectors (error messages, logging, side channels, etc.) unaddressed.
Authentication verifies actor identity and is a prerequisite for access decisions, yet addresses only one facet of the broad set of exposure vectors in CWE-200.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Restricting anonymous or unknown access and encrypting high-value information limits the exposure of sensitive data that would otherwise be obtainable by unauthorized actors.
Suppressing system details, error specifics, and previous log-on information until successful authentication reduces the information an unauthenticated attacker can gather.
By requiring owners to assign sensitivity labels and corresponding handling rules, the control ensures that information is not left unmarked and therefore reduces the chance that sensitive data will be exposed to unauthorized actors.
Requiring encryption, access controls, and recipient authentication for transfers directly reduces the chance that sensitive data reaches an unauthorized observer.
Secure delivery, protected storage, and confidentiality of allocation records limit exposure of authentication material to unauthorized observers.
Requiring defined procedures, assigned roles, and technical/organizational measures for handling PII reduces the chance that sensitive personal data will be exposed to unauthorized actors through inadequate handling or missing safeguards.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Ubuntu 22.04 (1 rule)
- V-260470 Ubuntu 22.04 LTS, when booted, must require authentication upon booting into single-user and maintenance modes. prevents CWE-200
Ubuntu 24.04 (2 rules)
- V-270647 Ubuntu 24.04 LTS must not have the telnet package installed. prevents CWE-200
- V-270675 Ubuntu 24.04 LTS when booted must require authentication upon booting into single-user and maintenance modes. prevents CWE-200
Windows 10 (1 rule)
- V-220737 Administrative accounts must not be used with applications that access the Internet, such as web browsers, or with potential Internet sources, such as email. prevents CWE-200
Windows Server 2016 (1 rule)
- V-224974 Domain-created Active Directory Organizational Unit (OU) objects must have proper access control permissions. prevents CWE-200
Windows Server 2019 (1 rule)
- V-205743 Windows Server 2019 organization created Active Directory Organizational Unit (OU) objects must have proper access control permissions. prevents CWE-200
Windows Server 2022 (1 rule)
- V-254395 Windows Server 2022 organization created Active Directory Organizational Unit (OU) objects must have proper access control permissions. prevents CWE-200