Cloudreve EUVD-2026-84528

Requires an authenticated account holding Files.Write permission - satisfied by the default User group - and the default local-storage policy, both explicitly stated as affected, so no non-default configuration is needed. Exploitation depends on issuing genuinely concurrent upload-session requests so they read the same in-memory capacity snapshot before any storage charge commits (the TOCTOU window in PrepareUpload/validateUserCapacity vs. CommitWithStorageDiff). Limiting factors: the attacker must already have a valid low-privileged account (PR:L, not unauthenticated), and impact is confined to storage exhaustion / denial of uploads - no data disclosure or code execution.

This is a genuine availability risk but not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H = 7.1) correctly frames it as a network-reachable, low-complexity flaw requiring only a low-privileged authenticated account (any member of the default User group with Files.Write). The impact is availability-dominant (A:H - host storage exhaustion denying uploads to all tenants) with a secondary integrity effect (I:L - per-user storage accounting is corrupted so reservations exceed quota) and no confidentiality impact (C:N). No EPSS score, KEV listing, or public POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation - this is a disclosed-and-patched TOCTOU quota-bypass, not an actively-weaponized bug. Note the input Tag 'Information Disclosure' directly contradicts the CVSS vector (C:N): there is no confidentiality impact, so that tag is mislabeled and should be treated as a DoS/race-condition issue. The real-world weight of this CVE is therefore moderate: trivially triggerable by any authenticated user in a default configuration, but bounded to denial-of-service against a niche self-hosted product with no confidentiality exposure.

A low-privileged authenticated Cloudreve user with Files.Write permission (the default User group) fires many concurrent create-upload-session requests. Because each request validates capacity against the same stale in-memory storage snapshot before the storage charge is applied outside the quota-enforcing transaction, all requests pass the MaxStorage check and reserve their declared sizes. The attacker then materializes the over-committed reservations as chunked uploads, exhausting host disk and denying uploads to every other user. No public exploit code was identified at time of analysis.