Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.18.0, 4.0.0-20260715025621-7329602751c0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- cloudreve cloudreve
fixed in 4.18.0
- github.com/cloudreve/Cloudreve/v4Go
fixed in 4.0.0-20260715025621-7329602751c0
- github.com/cloudreve/CloudreveGo
All versions
- github.com/cloudreve/Cloudreve/v3Go
All versions