Apache CloudStack security advisories

Security information for Apache CloudStack

Reporting

Do you want disclose a potential security issue for Apache CloudStack? You can read more about the projects’ security policy on their security page, and email your report to the Apache Security Team.

Advisories

This section is experimental: it provides advisories since 2023 and may lag behind the official CVE publications. It may also lack details found on the project security page. If you have any feedback on how you would like this data to be provided, you are welcome to reach out on our public mailinglist or privately on security@apache.org

Proxmox Extension Allows Unauthorized Cross-Tenant Instance Access

CVE-2026-25199 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:23:04.078Z

Affected

  • Apache CloudStack from 4.21.0 through 4.22.0

Description

Instances deployed via the Proxmox extension allow unauthorized access to instances belonging to other tenants.

This issue affects Apache CloudStack: from 4.21.0.0 through 4.22.0.0.

The Proxmox extension for CloudStack improperly uses a user-editable instance setting, proxmox_vmid, to associate CloudStack instances with Proxmox virtual machines. Because this value is not restricted or validated against tenant ownership and Proxmox VM IDs are predictable, a non-privileged attacker can modify the setting to reference a VM belonging to another account. This allows unauthorized cross-tenant access and enables full control over the targeted VM, including starting, stopping, and destroying the virtual machine.

Users are recommended to upgrade to version 4.22.0.1, which fixes this issue.

As a workaround for the existing installations, editing of the proxmox_vmid instance detail by users can be prevented by adding this detail name to the global configuration parameter - user.vm.denied.details.

References

Credits

Unauthenticated Command Injection in Direct Download Templates

CVE-2026-25077 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:21:33.362Z

Affected

  • Apache CloudStack from 4.11.0 through 4.20.2.0
  • Apache CloudStack from 4.21.0.0 through 4.22.0.0

Description

Account users are allowed by default to register templates to be downloaded directly to the primary storage for deploying instances using the KVM hypervisor. Due to missing file name sanitization, an attacker can register malicious templates to execute arbitrary code on the KVM hosts. This can result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of the KVM-based infrastructure managed by CloudStack.

Users are recommended to upgrade to Apache CloudStack versions 4.20.3.0 or 4.22.0.1, or later, which fixes this issue.

References

Credits

Domain/account resources limits not honored

CVE-2025-69233 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:19:36.271Z

Affected

  • Apache CloudStack from 4.0.0 through 4.20.2.0
  • Apache CloudStack from 4.21.0.0 through 4.22.0.0

Description

Due to multiple time-of-check time-of-use race conditions in the resource count check and increment logic, as well as missing validations, users of the platform are able to exceed the allocation limits configured for their accounts/domains. This can be used by an attacker to degrade the infrastructure’s resources and lead to denial of service conditions.

Users are recommended to upgrade to Apache CloudStack versions 4.20.3.0 or 4.22.0.1, or later, which fixes this issue.

References

Credits

MinIO policy remains intact on bucket deletion

CVE-2025-66467 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:16:09.128Z

Affected

  • Apache CloudStack from 4.19.0.0 through 4.20.2.0
  • Apache CloudStack from 4.21.0.0 through 4.22.0.0

Description

Missing MinIO policy cleanup on bucket deletion via Apache CloudStack allows users to retain access to buckets which they previously owned. If another user creates a new bucket with the same name, the previous owners can gain unauthorized read and write access to it by using the previously generated access and secret keys.

Users are recommended to upgrade to Apache CloudStack versions 4.20.3.0 or 4.22.0.1, or later, which fixes this issue.

References

Credits

Any user can attach a volume in their VMs from backups they should not have access to

CVE-2025-66172 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:13:30.758Z

Affected

  • Apache CloudStack from 4.21.0.0 through 4.22.0.0

Description

The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can restore a volume from any other user’s backups and attach the volume to their own VMs.

Backup plugin users using CloudStack 4.21.0.0+ are recommended to upgrade to CloudStack version 4.22.0.1, which fixes this issue.

References

Credits

  • Gabriel Pordeus (reporter)

Any user can create a new VM from backups they should not have access to

CVE-2025-66171 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:11:10.736Z

Affected

  • Apache CloudStack from 4.21.0.0 through 4.22.0.0

Description

The CloudStack Backup plugin has an improper access logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and have access to specific APIs can create new VMs using backups of any other user of the environment.

Backup plugin users using CloudStack 4.21.0.0+ are recommended to upgrade to CloudStack version 4.22.0.1, which fixes this issue.

References

Credits

Any user can list backups that they should not have access to

CVE-2025-66170 [CVE] [CVE json] [OSV json]

Last updated: 2026-05-08T12:06:38.994Z

Affected

  • Apache CloudStack from 4.21.0.0 through 4.22.0.0

Description

The CloudStack Backup plugin has an improper authorization logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and has access to specific APIs can list backups from any account in the environment. This vulnerability does not allow them to see the contents of the backup.

Users are recommended to upgrade to version 4.22.0.1, which fixes the issue.

References

Credits

Lack of user permission validation leading to data leak for few APIs

CVE-2025-59454 [CVE] [CVE json] [OSV json]

Last updated: 2025-11-27T11:40:37.834Z

Affected

  • Apache CloudStack from 4.0.0 before 4.20.2
  • Apache CloudStack from 4.21.0 before 4.22.0

Description

In Apache CloudStack, a gap in access control checks affected the APIs 

- createNetworkACL


    

  • listNetworkACLs
    • 

  • listResourceDetails
    • 

  • listVirtualMachinesUsageHistory
    • 

  • listVolumesUsageHistory
While these APIs were accessible only to authorized users, insufficient permission validation meant that users could occasionally access information beyond their intended scope.

Users are recommended to upgrade to Apache CloudStack 4.20.2.0 or 4.22.0.0, which fixes the issue.

References

Credits

Potential remote code execution on Javascript engine defined rules

CVE-2025-59302 [CVE] [CVE json] [OSV json]

Last updated: 2025-11-27T11:46:23.798Z

Affected

  • Apache CloudStack from 4.18.0 before 4.20.2
  • Apache CloudStack from 4.21.0 before 4.22.0

Description

In Apache CloudStack improper control of generation of code ('Code Injection') vulnerability is found in the following APIs which are accessible only to admins.

  • quotaTariffCreate
  • quotaTariffUpdate
  • createSecondaryStorageSelector
  • updateSecondaryStorageSelector
  • updateHost
  • updateStorage

This issue affects Apache CloudStack: from 4.18.0 before 4.20.2, from 4.21.0 before 4.22.0. Users are recommended to upgrade to versions 4.20.2 or 4.22.0, which contain the fix.

The fix introduces a new global configuration flag, js.interpretation.enabled, allowing administrators to control the interpretation of JavaScript expressions in these APIs, thereby mitigating the code injection risk.

References

Credits

Insecure access of user’s API/Secret Keys in the same domain

CVE-2025-47849 [CVE] [CVE json] [OSV json]

Last updated: 2025-06-11T03:59:42.176Z

Affected

  • Apache CloudStack from 4.10.0 before 4.19.3.0
  • Apache CloudStack from 4.20.0.0 before 4.20.1.0

Description

A privilege escalation vulnerability exists in Apache CloudStack versions 4.10.0.0 through 4.20.0.0 where a malicious Domain Admin user in the ROOT domain can get the API key and secret key of user-accounts of Admin role type in the same domain. This operation is not appropriately restricted and allows the attacker to assume control over higher-privileged user-accounts. A malicious Domain Admin attacker can impersonate an Admin user-account and gain access to sensitive APIs and resources that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of infrastructure managed by CloudStack.

Users are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0, which fixes the issue with the following:
  • Strict validation on Role Type hierarchy: the caller's role must be equal to or higher than the target user's role. 
  • API privilege comparison: the caller must possess all privileges of the user they are operating on. 
  • Two new domain-level settings (restricted to the default admin): 
     - role.types.allowed.for.operations.on.accounts.of.same.role.type: Defines which role types are allowed to act on users of the same role type. Default: "Admin, DomainAdmin, ResourceAdmin". 
     - allow.operations.on.users.in.same.account: Allows/disallows user operations within the same account. Default: true.

References

Credits

Domain Admin can reset Admin password in Root Domain

CVE-2025-47713 [CVE] [CVE json] [OSV json]

Last updated: 2025-06-11T03:59:55.628Z

Affected

  • Apache CloudStack from 4.10.0 before 4.19.3.0
  • Apache CloudStack from 4.20.0.0 before 4.20.1.0

Description

A privilege escalation vulnerability exists in Apache CloudStack versions 4.10.0.0 through 4.20.0.0 where a malicious Domain Admin user in the ROOT domain can reset the password of user-accounts of Admin role type. This operation is not appropriately restricted and allows the attacker to assume control over higher-privileged user-accounts. A malicious Domain Admin attacker can impersonate an Admin user-account and gain access to sensitive APIs and resources that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of infrastructure managed by CloudStack.

Users are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0, which fixes the issue with the following:
  • Strict validation on Role Type hierarchy: the caller's user-account role must be equal to or higher than the target user-account's role.
  • API privilege comparison: the caller must possess all privileges of the user they are operating on.
  • Two new domain-level settings (restricted to the default Admin):
     - role.types.allowed.for.operations.on.accounts.of.same.role.type: Defines which role types are allowed to act on users of the same role type. Default: "Admin, DomainAdmin, ResourceAdmin".
       - allow.operations.on.users.in.same.account: Allows/disallows user operations within the same account. Default: true.

References

Credits

Unauthorised template/ISO list access to the domain/resource admins

CVE-2025-30675 [CVE] [CVE json] [OSV json]

Last updated: 2025-06-11T04:00:06.854Z

Affected

  • Apache CloudStack from 4.0.0 before 4.19.3.0
  • Apache CloudStack from 4.20.0.0 before 4.20.1.0

Description

In Apache CloudStack, a flaw in access control affects the listTemplates and listIsos APIs. A malicious Domain Admin or Resource Admin can exploit this issue by intentionally specifying the 'domainid' parameter along with the 'filter=self' or 'filter=selfexecutable' values. This allows the attacker to gain unauthorized visibility into templates and ISOs under the ROOT domain.
A malicious admin can enumerate and extract metadata of templates and ISOs that belong to unrelated domains, violating isolation boundaries and potentially exposing sensitive or internal configuration details. 
This vulnerability has been fixed by ensuring the domain resolution strictly adheres to the caller's scope rather than defaulting to the ROOT domain.

Affected users are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0.

References

Credits

CKS cluster in project exposes user API keys

CVE-2025-26521 [CVE] [CVE json] [OSV json]

Last updated: 2025-06-11T04:00:17.648Z

Affected

  • Apache CloudStack from 4.17.0.0 before 4.19.3.0
  • Apache CloudStack from 4.20.0.0 before 4.20.1.0

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 Projects

A 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 Account

Create 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 Project

Add this account to the project where the Kubernetes cluster(s) are hosted.

3. Generate API and Secret Keys

Generate API Key and Secret Key for the default user of this account.

4. Update the CloudStack Secret in the Kubernetes Cluster

Create 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-config

5. Regenerate API and Secret Keys

Regenerate the API and secret keys for the original user account that was used to create the Kubernetes cluster.

References

Credits

Unauthorised access to dedicated resources in Quota plugin

CVE-2025-22829 [CVE] [CVE json] [OSV json]

Last updated: 2025-06-11T04:00:28.410Z

Affected

  • Apache CloudStack from 4.20.0.0 before 4.20.1.0

Description

The CloudStack Quota plugin has an improper privilege management logic in version 4.20.0.0. Anyone with authenticated user-account access in CloudStack 4.20.0.0 environments, where this plugin is enabled and have access to specific APIs can enable or disable reception of quota-related emails for any account in the environment and list their configurations.

Quota plugin users using CloudStack 4.20.0.0 are recommended to upgrade to CloudStack version 4.20.1.0, which fixes this issue.

References

Credits

Unauthorised access to annotations

CVE-2025-22828 [CVE] [CVE json] [OSV json]

Last updated: 2025-01-13T12:40:18.771Z

Affected

  • Apache CloudStack from 4.16.0 through *

Description

CloudStack users can add and read comments (annotations) on resources they are authorised to access. 
Due to an access validation issue that affects Apache CloudStack versions from 4.16.0, users who have access, prior access or knowledge of resource UUIDs can list and add comments (annotations) to such resources. 
An attacker with a user-account and access or prior knowledge of resource UUIDs may exploit this issue to read contents of the comments (annotations) or add malicious comments (annotations) to such resources. 
This may cause potential loss of confidentiality of CloudStack environments and resources if the comments (annotations) contain any privileged information. However, guessing or brute-forcing resource UUIDs are generally hard to impossible and access to listing or adding comments isn't same as access to CloudStack resources, making this issue of very low severity and general low impact.

CloudStack admins may also disallow listAnnotations and addAnnotation API access to non-admin roles in their environment as an interim measure.

References

Credits

Directly downloaded templates can be used to abuse KVM-based infrastructure

CVE-2024-50386 [CVE] [CVE json] [OSV json]

Last updated: 2024-11-12T13:52:37.947Z

Affected

  • Apache CloudStack from 4.0.0 through 4.18.2.4
  • Apache CloudStack from 4.19.0.0 through 4.19.1.2

Description

Account users in Apache CloudStack by default are allowed to register templates to be downloaded directly to the primary storage for deploying instances. Due to missing validation checks for KVM-compatible templates in CloudStack 4.0.0 through 4.18.2.4 and 4.19.0.0 through 4.19.1.2, an attacker that can register templates, can use them to deploy malicious instances on KVM-based environments and exploit this to gain access to the host filesystems that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of KVM-based infrastructure managed by CloudStack.


Users are recommended to upgrade to Apache CloudStack 4.18.2.5 or 4.19.1.3, or later, which addresses this issue.

Additionally, all user-registered KVM-compatible templates can be scanned and checked that they are flat files that should not be using any additional or unnecessary features. For example, operators can run the following command on their file-based primary storage(s) and inspect the output. An empty output for the disk being validated means it has no references to the host filesystems; on the other hand, if the output for the disk being validated is not empty, it might indicate a compromised disk. However, bear in mind that (i) volumes created from templates will have references for the templates at first and (ii) volumes can be consolidated while migrating, losing their references to the templates. Therefore, the command execution for the primary storages can show both false positives and false negatives.
for file in $(find /path/to/storage/ -type f -regex [a-f0-9-].); do echo “Retrieving file [$file] info. If the output is not empty, that might indicate a compromised disk; check it carefully.”; qemu-img info -U $file | grep file: ; printf “\n\n”; done

For checking the whole template/volume features of each disk, operators can run the following command:
for file in $(find /path/to/storage/ -type f -regex [a-f0-9-].); do echo “Retrieving file [$file] info.”; qemu-img info -U $file; printf “\n\n”; done


References

Credits

Request origin validation bypass makes account takeover possible

CVE-2024-45693 [CVE] [CVE json] [OSV json]

Last updated: 2024-10-16T10:39:13.974Z

Affected

  • Apache CloudStack from 4.15.1.0 through 4.18.2.3
  • Apache CloudStack from 4.19.0.0 through 4.19.1.1

Description

Users logged into the Apache CloudStack's web interface can be tricked to submit malicious CSRF requests due to missing validation of the origin of the requests. This can allow an attacker to gain privileges and access to resources of the authenticated users and may lead to account takeover, disruption, exposure of sensitive data and compromise integrity of the resources owned by the user account that are managed by the platform.

This issue affects Apache CloudStack from 4.15.1.0 through 4.18.2.3 and 4.19.0.0 through 4.19.1.1

Users are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue.

References

Credits

  • Arthur Souza (reporter)
  • Felipe Olivaes (reporter)

Incomplete session invalidation on web interface logout

CVE-2024-45462 [CVE] [CVE json] [OSV json]

Last updated: 2024-10-16T10:39:03.528Z

Affected

  • Apache CloudStack from 4.15.1.0 through 4.18.2.3
  • Apache CloudStack from 4.19.0.0 through 4.19.1.1

Description

The logout operation in the CloudStack web interface does not expire the user session completely which is valid until expiry by time or restart of the backend service. An attacker that has access to a user's browser can use an unexpired session to gain access to resources owned by the logged out user account. This issue affects Apache CloudStack from 4.15.1.0 through 4.18.2.3; and from 4.19.0.0 through 4.19.1.1.

Users are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue.

References

Credits

  • Arthur Souza (reporter)
  • Felipe Olivaes (reporter)

Access checks not enforced in Quota

CVE-2024-45461 [CVE] [CVE json] [OSV json]

Last updated: 2025-02-12T09:30:16.539Z

Affected

  • Apache CloudStack Quota plugin from 4.7.0 through 4.18.2.3
  • Apache CloudStack Quota plugin from 4.19.0.0 through 4.19.1.1

Description

The CloudStack Quota feature allows cloud administrators to implement a quota or usage limit system for cloud resources, and is disabled by default. In environments where the feature is enabled, due to missing access check enforcements, non-administrative CloudStack user accounts are able to access and modify quota-related configurations and data. This issue affects Apache CloudStack from 4.7.0 through 4.18.2.3; and from 4.19.0.0 through 4.19.1.1, where the Quota feature is enabled.

Users are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue. Alternatively, users that do not use the Quota feature are advised to disabled the plugin by setting the global setting "quota.enable.service" to "false".

References

Credits

Uploaded and registered templates and volumes can be used to abuse KVM-based infrastructure

CVE-2024-45219 [CVE] [CVE json] [OSV json]

Last updated: 2024-10-15T18:32:48.536Z

Affected

  • Apache CloudStack from 4.0.0 through 4.18.2.3
  • Apache CloudStack from 4.19.0.0 through 4.19.1.1

Description

Account users in Apache CloudStack by default are allowed to upload and register templates for deploying instances and volumes for attaching them as data disks to their existing instances. Due to missing validation checks for KVM-compatible templates or volumes in CloudStack 4.0.0 through 4.18.2.3 and 4.19.0.0 through 4.19.1.1, an attacker that can upload or register templates and volumes, can use them to deploy malicious instances or attach uploaded volumes to their existing instances on KVM-based environments and exploit this to gain access to the host filesystems that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of KVM-based infrastructure managed by CloudStack.


Users are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue.

Additionally, all user-uploaded or registered KVM-compatible templates and volumes can be scanned and checked that they are flat files that should not be using any additional or unnecessary features. For example, operators can run this on their secondary storage(s) and inspect output. An empty output for the disk being validated means it has no references to the host filesystems; on the other hand, if the output for the disk being validated is not empty, it might indicate a compromised disk.
for file in $(find /path/to/storage/ -type f -regex [a-f0-9-].); do echo “Retrieving file [$file] info. If the output is not empty, that might indicate a compromised disk; check it carefully.”; qemu-img info -U $file | grep file: ; printf “\n\n”; done

The command can also be run for the file-based primary storages; however, bear in mind that (i) volumes created from templates will have references for the templates at first and (ii) volumes can be consolidated while migrating, losing their references to the templates. Therefore, the command execution for the primary storages can show both false positives and false negatives.

For checking the whole template/volume features of each disk, operators can run the following command:
for file in $(find /path/to/storage/ -type f -regex [a-f0-9-].); do echo “Retrieving file [$file] info.”; qemu-img info -U $file; printf “\n\n”; done

References

Credits

Unauthorised Network List Access

CVE-2024-42222 [CVE] [CVE json] [OSV json]

Last updated: 2024-08-07T06:49:40.024Z

Affected

  • Apache CloudStack at 4.19.1.0

Description

In Apache CloudStack 4.19.1.0, a regression in the network listing API allows unauthorised list access of network details for domain admin and normal user accounts. This vulnerability compromises tenant isolation, potentially leading to unauthorised access to network details, configurations and data.

Affected users are advised to upgrade to version 4.19.1.1 to address this issue. Users on older versions of CloudStack considering to upgrade, can skip 4.19.1.0 and upgrade directly to 4.19.1.1.

References

Credits

  • Christian Gross of Netcloud AG (finder)
  • Midhun Jose (finder)

User Key Exposure to Domain Admins

CVE-2024-42062 [CVE] [CVE json] [OSV json]

Last updated: 2024-08-19T13:43:36.243Z

Affected

  • Apache CloudStack from 4.10.0 through 4.18.2.2
  • Apache CloudStack from 4.19.0.0 through 4.19.1.0

Description

CloudStack account-users by default use username and password based authentication for API and UI access. Account-users can generate and register randomised API and secret keys and use them for the purpose of API-based automation and integrations. Due to an access permission validation issue that affects Apache CloudStack versions 4.10.0 up to 4.19.1.0, domain admin accounts were found to be able to query all registered account-users API and secret keys in an environment, including that of a root admin. An attacker who has domain admin access can exploit this to gain root admin and other-account privileges and perform malicious operations that can result in compromise of resources integrity and confidentiality, data loss, denial of service and availability of CloudStack managed infrastructure.

Users are recommended to upgrade to Apache CloudStack 4.18.2.3 or 4.19.1.1, or later, which addresses this issue. Additionally, all account-user API and secret keys should be regenerated.

References

Credits

  • Fabricio Duarte (finder)

SAML Signature Exclusion

CVE-2024-41107 [CVE] [CVE json] [OSV json]

Last updated: 2024-07-19T10:11:15.224Z

Affected

  • Apache CloudStack from 4.5.0 through 4.18.2.1
  • Apache CloudStack from 4.19.0.0 through 4.19.0.2

Description

The CloudStack SAML authentication (disabled by default) does not enforce signature check. In CloudStack environments where SAML authentication is enabled, an attacker that initiates CloudStack SAML single sign-on authentication can bypass SAML authentication by submitting a spoofed SAML response with no signature and known or guessed username and other user details of a SAML-enabled CloudStack user-account. In such environments, this can result in a complete compromise of the resources owned and/or accessible by a SAML enabled user-account.

Affected users are recommended to disable the SAML authentication plugin by setting the "saml2.enabled" global setting to "false", or upgrade to version 4.18.2.2, 4.19.1.0 or later, which addresses this issue.

References

Credits

  • Christian Gross of Netcloud AG (finder)
  • Damon Smith of Apple Services Engineering Security (finder)
  • Adam Pond of Apple Services Engineering Security (finder)
  • Terry Thibault of Apple Services Engineering Security (finder)

Integration API service uses dynamic port when disabled

CVE-2024-39864 [CVE] [CVE json] [OSV json]

Last updated: 2024-07-05T13:39:23.006Z

Affected

  • Apache CloudStack from 4.0.0 through 4.18.2.0
  • Apache CloudStack from 4.19.0.0 through 4.19.0.1

Description

The CloudStack integration API service allows running its unauthenticated API server (usually on port 8096 when configured and enabled via integration.api.port global setting) for internal portal integrations and for testing purposes. By default, the integration API service port is disabled and is considered disabled when integration.api.port is set to 0 or negative. Due to an improper initialisation logic, the integration API service would listen on a random port when its port value is set to 0 (default value). An attacker that can access the CloudStack management network could scan and find the randomised integration API service port and exploit it to perform unauthorised administrative actions and perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure.

Users are recommended to restrict the network access on the CloudStack management server hosts to only essential ports. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue.

References

Credits

  • Adam Pond of Apple Services Engineering Security (finder)
  • Terry Thibault of Apple Services Engineering Security (finder)
  • Damon Smith of Apple Services Engineering Security (finder)

Unauthenticated cluster service port leads to remote execution

CVE-2024-38346 [CVE] [CVE json] [OSV json]

Last updated: 2024-07-05T13:39:11.185Z

Affected

  • Apache CloudStack from 4.0.0 through 4.18.2.0
  • Apache CloudStack from 4.19.0.0 through 4.19.0.1

Description

The CloudStack cluster service runs on unauthenticated port (default 9090) that can be misused to run arbitrary commands on targeted hypervisors and CloudStack management server hosts. Some of these commands were found to have command injection vulnerabilities that can result in arbitrary code execution via agents on the hosts that may run as a privileged user. An attacker that can reach the cluster service on the unauthenticated port (default 9090), can exploit this to perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure.


Users are recommended to restrict the network access to the cluster service port (default 9090) on a CloudStack management server host to only its peer CloudStack management server hosts. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue.

References

Credits

  • Adam Pond of Apple Services Engineering Security (finder)
  • Terry Thibault of Apple Services Engineering Security (finder)
  • Damon Smith of Apple Services Engineering Security (finder)

The extraconfig feature can be abused to load hypervisor resources on a VM instance

CVE-2024-29008 [CVE] [CVE json] [OSV json]

Last updated: 2024-04-04T10:58:44.745Z

Affected

  • Apache CloudStack from 4.14.0.0 through 4.18.1.0, 4.19.0.0

Description

A problem has been identified in the CloudStack additional VM configuration (extraconfig) feature which can be misused by anyone who has privilege to deploy a VM instance or configure settings of an already deployed VM instance, to configure additional VM configuration even when the feature is not explicitly enabled by the administrator. In a KVM based CloudStack environment, an attacker can exploit this issue to attach host devices such as storage disks, and PCI and USB devices such as network adapters and GPUs, in a regular VM instance that can be further exploited to gain access to the underlying network and storage infrastructure resources, and access any VM instance disks on the local storage.

Users are advised to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue.

References

Credits

When downloading templates or ISOs, the management server and SSVM follow HTTP redirects with potentially dangerous consequences

CVE-2024-29007 [CVE] [CVE json] [OSV json]

Last updated: 2024-04-04T10:58:20.239Z

Affected

  • Apache CloudStack from 4.9.1.0 through 4.18.1.0, 4.19.0.0

Description

The CloudStack management server and secondary storage VM could be tricked into making requests to restricted or random resources by means of following 301 HTTP redirects presented by external servers when downloading templates or ISOs. Users are recommended to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue.

References

Credits

x-forwarded-for HTTP header parsed by default

CVE-2024-29006 [CVE] [CVE json] [OSV json]

Last updated: 2024-04-04T10:59:16.384Z

Affected

  • Apache CloudStack from 4.11.0.0 through 4.18.1.0, 4.19.0.0

Description

By default the CloudStack management server honours the x-forwarded-for HTTP header and logs it as the source IP of an API request. This could lead to authentication bypass and other operational problems should an attacker decide to spoof their IP address this way. Users are recommended to upgrade to CloudStack version 4.18.1.1 or 4.19.0.1, which fixes this issue.

References

Credits

Apache CloudStack SAML Single Sign-On XXE

CVE-2022-35741 [CVE] [CVE json] [OSV json]

Last updated: 2022-07-18T14:26:13.768Z

Affected

  • Apache CloudStack from 4.5.0 before Apache CloudStack*

Description

Apache CloudStack version 4.5.0 and later has a SAML 2.0 authentication Service Provider plugin which is found to be vulnerable to XML external entity (XXE) injection. This plugin is not enabled by default and the attacker would require that this plugin be enabled to exploit the vulnerability. When the SAML 2.0 plugin is enabled in affected versions of Apache CloudStack could potentially allow the exploitation of XXE vulnerabilities. The SAML 2.0 messages constructed during the authentication flow in Apache CloudStack are XML-based and the XML data is parsed by various standard libraries that are now understood to be vulnerable to XXE injection attacks such as arbitrary file reading, possible denial of service, server-side request forgery (SSRF) on the CloudStack management server.

References

Credits

  • This issue was reported by v3ged0ge

Apache Cloudstack insecure random number generation affects project email invitation

CVE-2022-26779 [CVE] [CVE json] [OSV json]

Last updated: 2022-07-13T11:28:52.383Z

Affected

  • Apache CloudStack from Apache CloudStack before 4.16.1

Description

Apache CloudStack prior to 4.16.1.0 used insecure random number generation for project invitation tokens. If a project invite is created based only on an email address, a random token is generated. An attacker with knowledge of the project ID and the fact that the invite is sent, could generate time deterministic tokens and brute force attempt to use them prior to the legitimate receiver accepting the invite. This feature is not enabled by default, the attacker is required to know or guess the project ID for the invite in addition to the invitation token, and the attacker would need to be an existing authorized user of CloudStack.

References

Credits

  • This issue was reported by Jonathan Leitschuh