VulnerabilityPublished 10 Jun 2025Updated 26 Feb 2026

CVE-2025-26521: Apache CloudStack · Information Exposure

Affects Apache CloudStackSource CVE Database V5

Not known to be exploited · CVSS 8.1 High · fixed in 4.19.3.0 : patch Apache CloudStack soon.

Data as of 26 Oct 2026, 10:12 UTC

CVSS 3.1 base score

8.1High

How severe the flaw is on the 0–10 CVSS scale.

EPSS: 0.6% chance of exploitation in 30 days – higher than 51% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 4.19.3.0

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Attack Vector: Network
Attack Complexity: Low
Privileges Required: Low
User Interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: Low: The attacker is authorized with (i.e., requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: High: There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.
Integrity: High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
Availability: None: There is no impact to availability within the impacted component.

Definitions: FIRST CVSS v3.1 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 10 Jun 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Affected software

Product	Affected	Fixed in
Mavenorg.apache.cloudstack/cloudstack`pkg:maven/org.apache.cloudstack/cloudstack`Other threats	Affected =4.17.0.0 =4.20.0.0	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Upgrade Apache CloudStack to versions 4.19.3.0 or 4.20.1.0 where the vulnerability is fixed.
Implement the recommended service account model: create a dedicated service account with the 'Project Kubernetes Service Role' for Kubernetes cluster management, limiting permissions to only what is necessary.
Add the service account to the relevant project and generate new API and secret keys for it.
Update the Kubernetes cluster secret to use the new service account credentials by deleting the existing 'cloudstack-secret' and creating a new one with the updated keys.
Regenerate the original user's API and secret keys to invalidate any exposed credentials.
Review project membership and Kubernetes cluster access controls to ensure only authorized users have access.
Monitor API key usage and audit logs for suspicious activity related to Kubernetes clusters and project resources.
Educate administrators and users about the risks of credential exposure within shared projects and enforce the principle of least privilege for all accounts. These steps go beyond generic patching by restructuring credential management and access control to minimize future exposure risks.

Description

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. 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.

Impact

The vulnerability allows unauthorized project members to access sensitive API credentials of the cluster creator, enabling them to impersonate the creator and perform privileged actions. This can lead to a complete compromise of the confidentiality, integrity, and availability of cloud resources owned by the creator's account. Potential impacts include unauthorized data access or exfiltration, modification or deletion of cloud resources, disruption of services, and lateral movement within the cloud infrastructure. Organizations using affected versions of Apache CloudStack in multi-tenant or collaborative project environments face significant risks, especially if project membership is not tightly controlled. The ease of exploitation is moderate since the attacker must have project membership and Kubernetes cluster access, but no user interaction is required. The scope is limited to projects using CKS-based Kubernetes clusters within the affected CloudStack versions, but given CloudStack's use in private and public clouds, the impact can be substantial in environments with multiple users and projects.

Summary

CVE-2025-26521 is a vulnerability classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) affecting Apache CloudStack, specifically versions 4.17.0.0 to 4.20.0.0. The issue arises when a user-account creates a CKS-based Kubernetes cluster within a project: the API key and secret key of the 'kubeadmin' user associated with the creator's account are embedded into the Kubernetes cluster's secret configuration. Because project members who have access to the Kubernetes cluster can retrieve this secret, they gain access to the creator's API credentials. This exposure enables an attacker with project membership to impersonate the cluster creator, allowing them to perform privileged operations that can compromise the confidentiality, integrity, and availability of the creator's cloud resources. The vulnerability does not require user interaction but does require the attacker to have project membership and access to the Kubernetes cluster. Apache has addressed this issue in versions 4.19.3.0 and 4.20.1.0 by recommending the use of dedicated service accounts with limited permissions for Kubernetes cluster operations. The mitigation process involves creating a new service account with the 'Project Kubernetes Service Role', adding it to the project, generating new API and secret keys for this account, updating the Kubernetes cluster secret to use these credentials, and regenerating the original user's API keys to invalidate the exposed credentials. This approach limits the scope of credentials exposed within the Kubernetes cluster and reduces the risk of privilege escalation or lateral movement within the cloud environment.

CWE-200Exposure of Sensitive Information to an Unauthorized Actor (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #20OWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design · Separation of Privilege
Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
OWASP Cheat Sheets
Error Handling (opens in a new tab)
Logging (opens in a new tab)
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.4 (opens in a new tab)
V14.3.3 (opens in a new tab)
V7.3.3 (opens in a new tab)
Attack patterns
Subverting Environment Variable Values (opens in a new tab)
ICMP Echo Request Ping (opens in a new tab)
TCP SYN Scan (opens in a new tab)
Enumerate Mail Exchange (MX) Records (opens in a new tab)
DNS Zone Transfers (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 27 Feb 2026, 01:21 UTC

WeaknessesCWE-200

Technical details

References

Community reviews

Related threats