What is the CVSS score of CVE-2025-66467?

CVE-2025-66467 has a CVSS 3.1 base score of 8.0 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Apache CloudStack are affected by CVE-2025-66467?

Apache CloudStack's MinIO integration contains a privilege escalation vulnerability that allows authenticated users to retain unauthorized access to buckets after deletion, potentially exposing…

How to fix or mitigate CVE-2025-66467?

Within 24 hours: Identify all CloudStack instances with MinIO integration and document current bucket naming conventions. Within 7 days: Upgrade to CloudStack 4.20.3.0 or 4.22.0.1 (or later). Within 30 days: Audit access key policies for all deleted buckets and revoke any keys associated with former bucket owners; implement bucket naming standards that eliminate reuse.

Apache CloudStack CVE-2025-66467

EUVD-2025-209743 HIGH

Incomplete Cleanup (CWE-459)

2026-05-08 apache

GHSA-8fr5-rq46-q395

Authentication Bypass Apache Apache Cloudstack Apache Software Foundation

8.0

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.0 HIGH

AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

May 08, 2026 - 14:00 vuln.today

CVE Published

May 08, 2026 - 12:16 nvd

HIGH 8.0

DescriptionCVE.org

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.

AnalysisAI

Apache CloudStack's MinIO integration fails to clean up bucket access policies when buckets are deleted, enabling previous bucket owners to retain unauthorized access via cached credentials. If another user creates a bucket with the same name, the former owner gains read/write access using their old access keys. CISA has not listed this CVE in KEV, indicating no confirmed widespread exploitation. CVSS 8.0 reflects high impact but requires authenticated access and user interaction (PR:L/UI:R), tempering immediate urgency. Patch available in CloudStack 4.20.3.0 and 4.22.0.1.

Technical ContextAI

This vulnerability stems from CWE-459 (Incomplete Cleanup) in Apache CloudStack's object storage integration with MinIO. CloudStack is an Infrastructure-as-a-Service platform managing cloud computing environments. When CloudStack provisions MinIO object storage buckets, it generates IAM-like policies granting bucket owners access keys. The affected product (CPE: apache_software_foundation:apache_cloudstack) fails to revoke these MinIO policies when buckets are deleted, leaving stale credentials active in MinIO's policy store. MinIO's bucket namespace is global within a deployment, so bucket name reuse by a different user creates a security boundary violation-the new bucket inherits the old policy mappings, granting the previous owner unintended access. The scope change (S:C) in CVSS indicates this crosses trust boundaries between CloudStack tenants.

RemediationAI

Upgrade to Apache CloudStack 4.20.3.0, 4.22.0.1, or later versions which implement proper MinIO policy cleanup on bucket deletion. The official advisory is available at https://lists.apache.org/thread/n8mt5b7wkpysstb8w7rr9f02kc5cq2xm. If immediate patching is not feasible, implement compensating controls: (1) disable bucket creation/deletion for untrusted users via CloudStack RBAC policies-this prevents attackers from triggering the bucket deletion scenario but limits self-service object storage functionality; (2) enforce unique bucket naming conventions using UUID prefixes or organizational namespaces to prevent name collisions-this reduces attack surface but requires changes to existing workflows and may break applications expecting user-defined bucket names; (3) audit MinIO policies manually and revoke orphaned credentials matching deleted buckets-this is operationally intensive and error-prone without automation. No workaround fully mitigates the vulnerability; patching is the only complete remediation.