https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 07:00:43 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-77633 <p>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.</p> <p>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.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-77633 https://vulnerability.circl.lu/vuln/ghsa-xj3h-wwxq-gfcj <p><strong>Affected:</strong> Go: github.com/cloudreve/Cloudreve/v4</p> <p>## Summary</p> <p>Cloudreve v4 splits the storage-quota **check** (reading the user&#39;s `used` bytes and comparing them to `MaxStorage`) and the **charge** (incrementing `users.storage`) into two non-atomic steps in the `PrepareUpload` code path. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Any authenticated user — including an unprivileged account in the default `User` group — can concurrently issue several upload-session requests that all read the same stale `used` snapshot, each pass the check, and then each contribute their declared `size` to `users.storage`. The end result is that the total approved capacity exceeds the group&#39;s `MaxStorage` many times over.</p> <p>The same primitive is trivially amplifiable into a storage-based denial of service. During `PrepareUpload`, Cloudreve reserves the declared size against `users.storage` before any bytes are written, so an attacker can push the reserved amount far beyond the host&#39;s physical disk (tested: a 1 GiB-quota account reserved 17 GiB in a single 20-way burst), and can then materialise the reservation by completing chunked uploads to actually write the excess bytes to disk. Amplification to the host&#39;s free space fills the disk and denies uploads for every user of the instance.</p> <p>Exploitation requires only a valid session with `Files.Write` permission. No administrator configuration, no non-default storage policy, and no elevated privileges are needed. The default deployment (local storage policy, default `User`…</p> <p><strong>Affected:</strong> Go: github.com/cloudreve/Cloudreve/v4</p> <p>## Summary</p> <p>Cloudreve v4 splits the storage-quota **check** (reading the user&#39;s `used` bytes and comparing them to `MaxStorage`) and the **charge** (incrementing `users.storage`) into two non-atomic steps in the `PrepareUpload` code path. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Any authenticated user — including an unprivileged account in the default `User` group — can concurrently issue several upload-session requests that all read the same stale `used` snapshot, each pass the check, and then each contribute their declared `size` to `users.storage`. The end result is that the total approved capacity exceeds the group&#39;s `MaxStorage` many times over.</p> <p>The same primitive is trivially amplifiable into a storage-based denial of service. During `PrepareUpload`, Cloudreve reserves the declared size against `users.storage` before any bytes are written, so an attacker can push the reserved amount far beyond the host&#39;s physical disk (tested: a 1 GiB-quota account reserved 17 GiB in a single 20-way burst), and can then materialise the reservation by completing chunked uploads to actually write the excess bytes to disk. Amplification to the host&#39;s free space fills the disk and denies uploads for every user of the instance.</p> <p>Exploitation requires only a valid session with `Files.Write` permission. No administrator configuration, no non-default storage policy, and no elevated privileges are needed. The default deployment (local storage policy, default `User`…</p> https://vulnerability.circl.lu/vuln/ghsa-xj3h-wwxq-gfcj