Apache CloudStack CVE-2025-66467

Requires a CloudStack deployment using MinIO-backed object storage. The attacker must be an authenticated CloudStack user (PR:L) who previously created and then deleted a bucket, retaining the still-valid access/secret keys that were never revoked in MinIO on deletion. Exploitation only succeeds when a different user subsequently creates a NEW bucket reusing the identical name - this name-collision precondition is outside the attacker's direct control and is the primary limiting factor. No user interaction from the victim is needed at exploit time, and the attack is remote over the S3/MinIO API. Not applicable to deployments not using the object-storage/MinIO feature or running fixed versions 4.20.3.0 / 4.22.0.1 or later.

This is a genuine but conditionally-gated access-control flaw rather than a mass-exploitation threat. The vendor CVSS of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects the total confidentiality and integrity loss over another user's object-storage bucket, and SSVC agrees the technical impact is 'total.' However, every other real-world signal points to low urgency: EPSS is 0.01% (3rd percentile), SSVC exploitation is 'none' and Automatable is 'no,' there is no CISA KEV listing, and no public exploit code was identified. The AC:L in the vendor vector is questionable - exploitation is not attacker-controlled end-to-end: it depends on the coincidental (or socially engineered) event of a DIFFERENT user later creating a new bucket with the exact same name that the attacker previously owned. That dependency argues for higher attack complexity than the vendor assigned. Net: a real integrity/confidentiality defect worth patching for any CloudStack deployment using MinIO-backed object storage, but not an emergency - no evidence of exploitation, opportunistic and non-automatable, and requires an authenticated foothold (PR:L).

An authenticated CloudStack user creates a MinIO-backed bucket, obtaining access/secret keys, then deletes the bucket - but the underlying MinIO policy is never cleaned up. Later, a second user creates a new bucket that happens to reuse the same name, and the original user replays their still-valid access/secret keys to read and write the new owner's data. No public exploit code exists and the attack is opportunistic rather than automatable.