Description

Cloudreve is a self-hosted file management and sharing system. Prior to 4.18.0, PrepareUpload in pkg/filemanager/fs/dbfs/upload.go checks a stale in-memory user storage value through validateUserCapacity and later applies an unconditional storage charge outside the same quota-enforcing transaction. An authenticated user with Files.Write permission can issue concurrent upload-session requests that read the same capacity snapshot, all pass the MaxStorage check, and reserve their declared sizes through CommitWithStorageDiff. The resulting reservations can exceed the account quota and can be materialized as chunked uploads that exhaust host storage and deny uploads to other users. The default local-storage policy and default User group are affected. This issue is fixed in version 4.18.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-22T16:17:55.817Z",
  "pubdate": "2026-09-22T16:17:55.817Z",
  "executiveSummary": "Cloudreve prior to version 4.18.0 is vulnerable to a race condition that allows authenticated users with Files.Write permissions to bypass configured storage quota limitations.\nThe vulnerability stems from a Time-of-Check to Time-of-Use (TOCTOU) flaw in the upload session management logic, where concurrent requests utilize a stale in-memory snapshot of user storage capacity.\nBy issuing simultaneous upload-session requests, an attacker can circumvent the MaxStorage validation check, leading to unauthorized storage reservations that exceed account quotas.\nThis can be weaponized to consume excessive disk space on the host server, resulting in a denial-of-service (DoS) condition where legitimate users are unable to perform file uploads due to exhausted storage resources.\nThe flaw affects the default local-storage policy and the default User group, requiring only authenticated access with basic write permissions to exploit.",
  "technicalDetails": "The root cause of this vulnerability is located in pkg/filemanager/fs/dbfs/upload.go within the PrepareUpload function. The implementation relies on a flawed state management mechanism for tracking user storage capacity. When a user initiates an upload, the application invokes validateUserCapacity, which evaluates the user's current storage status against a stale in-memory cache of their account's total capacity.\nCrucially, the storage charge is applied unconditionally and outside of the transaction scope used to enforce the quota. Because the verification and the subsequent commitment of the storage usage are not atomic, a race condition exists.\nAn attacker can exploit this by initiating multiple concurrent upload-session requests. Each request reads the same initial, stale capacity snapshot. Because the validation occurs simultaneously for all requests, each individual request independently passes the MaxStorage threshold check, as none of the concurrent requests have yet updated the global or database-level storage counters.\nSubsequently, the system processes these requests through CommitWithStorageDiff. The application commits the declared file sizes for all concurrent sessions, aggregating them into the user's storage quota consumption. Since these operations ignore the previous validation results and the state of other pending transactions, the cumulative reserved storage frequently exceeds the user's defined quota.\nThis allows a malicious user to force the system to materialize chunked uploads that occupy arbitrary amounts of disk space, effectively bypassing the server's governance policies. The attack flow involves the following sequence: 1) The attacker authenticates to the system with Files.Write privileges. 2) The attacker sends multiple parallel requests to initiate upload sessions. 3) The backend performs the validation for all requests using the same stale quota value. 4) The server processes the commits, resulting in an overflow of the intended quota. 5) Host storage is depleted as these excessive uploads persist on the local-storage filesystem.\nThe vulnerability affects versions prior to 4.18.0 and necessitates immediate remediation to prevent resource exhaustion attacks against the underlying infrastructure."
}