Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

22 Sep 2026 15:28:56 UTC

Source modified

25 Sep 2026 23:38:53 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

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.

Source published

Sep 22, 2026, 3:28:56 PM (timezone not stated)

Source modified

Sep 25, 2026, 11:38:53 PM (timezone not stated)

Observed here

11 Nov 2026 16:09:10 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

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.

Source published

22 Sep 2026 16:17:55 UTC

Source modified

26 Sep 2026 00:16:35 UTC

Observed here

25 Oct 2026 16:19:04 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

## Summary Cloudreve v4 splits the storage-quota **check** (reading the user'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's `MaxStorage` many times over. 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'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's free space fills the disk and denies uploads for every user of the instance. 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` group) is affected. ## Technical details `PrepareUpload` in `pkg/filemanager/fs/dbfs/upload.go` splits quota enforcement across two stages: **Stage A — the check (snapshot compare, no lock)** — `pkg/filemanager/fs/dbfs/validator.go`: ```go func (f *DBFS) validateUserCapacity(ctx context.Context, size int64, u *ent.User) error { capacity, err := f.Capacity(ctx, u) // reads "used" if err != nil { return ... } return f.validateUserCapacityRaw(ctx, size, capacity) } func (f *DBFS) validateUserCapacityRaw(ctx context.Context, size int64, capacity *fs.Capacity) error { if capacity.Used + size > capacity.Total { // snapshot compare only; no lock, no reservation return fs.ErrInsufficientCapacity } return nil } ``` `capacity.Used` comes from the in-memory `*ent.User` that was hydrated once at the beginning of the request — `pkg/filemanager/fs/dbfs/dbfs.go`: ```go func (f *DBFS) Capacity(ctx context.Context, u *ent.User) (*fs.Capacity, error) { ... res.Used = f.user.Storage // captured at request start res.Total = requesterGroup.MaxStorage return res, nil } ``` No SELECT is issued at check time, no row lock is taken on the user row, and pending upload sessions are not counted. **Stage B — the charge (single unconditional UPDATE, outside the tx)** — `pkg/filemanager/fs/dbfs/upload.go` → `inventory/tx.go` → `inventory/user.go`: ```go // PrepareUpload: check (A) ... then, many statements later ... if err := f.validateUserCapacity(ctx, req.Props.Size, ancestor.Owner()); err != nil { return nil, err } ... if err := inventory.CommitWithStorageDiff(ctx, dbTx, f.l, f.userClient); err != nil { ... } // charge (B) // inventory/user.go c.client.User.Update().Where(user.ID(uid)).AddStorage(diff).Exec(ctx) // SQL: storage = storage + diff ``` Between A and B the code performs storage-policy load-balancing, save-path generation, encryption-metadata generation, transaction start, placeholder-file/entity creation, and metadata upsert. This leaves a wide race window. `N` concurrent `PrepareUpload` requests each read the same stale `Used` snapshot at A, each pass their independent quota check, and then each add their own `size` to `users.storage` at B. The committed total is up to `N × size` above `MaxStorage`. Three defensive controls that would each independently close the race are missing: 1. The check and the charge are not enclosed in the same transaction with a `SELECT ... FOR UPDATE` on the user row. 2. The charge is a plain `storage = storage + :size` UPDATE, not an atomic conditional update of the form `UPDATE users SET storage = storage + :size WHERE id = :uid AND storage + :size <= :max_storage`. 3. `Used` is computed only from committed entities. Concurrent pending upload sessions (which have already been reserved by the accounting model) are not counted, so races among sessions that haven't yet completed are invisible to each other.

Source published

22 Sep 2026 20:40:33 UTC

Source modified

1 Oct 2026 20:55:42 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

Publisher rating · HIGH

Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service in github.com/cloudreve/Cloudreve

Source published

1 Oct 2026 20:23:38 UTC

Source modified

1 Oct 2026 20:45:15 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.