{"id":"CVE-2026-77633","aliases":["EUVD-2026-84528","GHSA-xj3h-wwxq-gfcj","GO-2026-6578"],"status":"published","title":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service","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.","severity":{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00368,"percentile":0.30942,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-362","CWE-367","CWE-770"],"published":"2026-09-22T15:28:56Z","modified":"2026-10-28T02:30:59Z","fixes":[{"ecosystem":"Go","package":"github.com/cloudreve/Cloudreve/v4","fixed_in":["4.0.0-20260715025621-7329602751c0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/cloudreve/Cloudreve/v4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.0.0-20260715025621-7329602751c0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/cloudreve/Cloudreve/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.0.0-20260715025621-7329602751c0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/cloudreve/Cloudreve","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/cloudreve/Cloudreve/v3","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/cloudreve/Cloudreve/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.0.0-20260715025621-7329602751c0"}]}]}],"products":[{"vendor":"cloudreve","product":"cloudreve"}],"references":[{"url":"https://github.com/cloudreve/cloudreve/security/advisories/GHSA-xj3h-wwxq-gfcj","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/cloudreve/cloudreve/commit/7329602751c00bb4136fe9ad8b364d0df70773df","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/cloudreve/cloudreve/releases/tag/4.18.0","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77633","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-xj3h-wwxq-gfcj"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/77xxx/CVE-2026-77633.json","tags":["advisory"]},{"url":"https://github.com/cloudreve/cloudreve","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-77633","title":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service","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.","status":"published","published":"2026-09-22T15:28:56.7Z","modified":"2026-09-25T23:38:53.232Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-362","CWE-367","CWE-770"],"updated_at":"2026-11-02T14:20:16.072351Z"}],"euvd":[{"id":"EUVD-2026-84528","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.","status":"published","published":"2026-09-22T15:28:56Z","modified":"2026-09-25T23:38:53Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high"}],"updated_at":"2026-11-02T17:27:54.622662Z"}],"ghsa":[{"id":"GHSA-xj3h-wwxq-gfcj","title":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service","description":"## Summary\n\nCloudreve 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.\n\nThe 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.\n\nExploitation 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.\n\n## Technical details\n\n`PrepareUpload` in `pkg/filemanager/fs/dbfs/upload.go` splits quota enforcement across two stages:\n\n**Stage A — the check (snapshot compare, no lock)** — `pkg/filemanager/fs/dbfs/validator.go`:\n\n```go\nfunc (f *DBFS) validateUserCapacity(ctx context.Context, size int64, u *ent.User) error {\n    capacity, err := f.Capacity(ctx, u)              // reads \"used\"\n    if err != nil { return ... }\n    return f.validateUserCapacityRaw(ctx, size, capacity)\n}\n\nfunc (f *DBFS) validateUserCapacityRaw(ctx context.Context, size int64, capacity *fs.Capacity) error {\n    if capacity.Used + size \u003e capacity.Total {       // snapshot compare only; no lock, no reservation\n        return fs.ErrInsufficientCapacity\n    }\n    return nil\n}\n```\n\n`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`:\n\n```go\nfunc (f *DBFS) Capacity(ctx context.Context, u *ent.User) (*fs.Capacity, error) {\n    ...\n    res.Used  = f.user.Storage            // captured at request start\n    res.Total = requesterGroup.MaxStorage\n    return res, nil\n}\n```\n\nNo SELECT is issued at check time, no row lock is taken on the user row, and pending upload sessions are not counted.\n\n**Stage B — the charge (single unconditional UPDATE, outside the tx)** — `pkg/filemanager/fs/dbfs/upload.go` → `inventory/tx.go` → `inventory/user.go`:\n\n```go\n// PrepareUpload: check (A) ...  then, many statements later ...\nif err := f.validateUserCapacity(ctx, req.Props.Size, ancestor.Owner()); err != nil {\n    return nil, err\n}\n...\nif err := inventory.CommitWithStorageDiff(ctx, dbTx, f.l, f.userClient); err != nil { ... }  // charge (B)\n\n// inventory/user.go\nc.client.User.Update().Where(user.ID(uid)).AddStorage(diff).Exec(ctx)  // SQL: storage = storage + diff\n```\n\nBetween 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`.\n\nThree defensive controls that would each independently close the race are missing:\n\n1. The check and the charge are not enclosed in the same transaction with a `SELECT ... FOR UPDATE` on the user row.\n2. 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 \u003c= :max_storage`.\n3. `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.","status":"published","published":"2026-09-22T20:40:33Z","modified":"2026-09-22T20:40:37Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high"}],"cwes":["CWE-362","CWE-367","CWE-770"],"updated_at":"2026-11-02T14:41:20.575159Z"}],"nvd":[{"id":"CVE-2026-77633","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.","status":"published","published":"2026-09-22T16:17:55.817Z","modified":"2026-09-26T00:16:35.823Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-362","CWE-367","CWE-770"],"updated_at":"2026-11-02T14:12:50.368368Z"}],"osv":[{"id":"CVE-2026-77633","title":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service","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.","status":"published","published":"2026-09-22T15:28:56.7Z","modified":"2026-10-28T02:30:59.568839052Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high"}],"cwes":["CWE-362","CWE-367","CWE-770"],"updated_at":"2026-11-02T15:45:17.44708Z"},{"id":"GHSA-xj3h-wwxq-gfcj","title":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service","description":"## Summary\n\nCloudreve 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.\n\nThe 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.\n\nExploitation 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.\n\n## Technical details\n\n`PrepareUpload` in `pkg/filemanager/fs/dbfs/upload.go` splits quota enforcement across two stages:\n\n**Stage A — the check (snapshot compare, no lock)** — `pkg/filemanager/fs/dbfs/validator.go`:\n\n```go\nfunc (f *DBFS) validateUserCapacity(ctx context.Context, size int64, u *ent.User) error {\n    capacity, err := f.Capacity(ctx, u)              // reads \"used\"\n    if err != nil { return ... }\n    return f.validateUserCapacityRaw(ctx, size, capacity)\n}\n\nfunc (f *DBFS) validateUserCapacityRaw(ctx context.Context, size int64, capacity *fs.Capacity) error {\n    if capacity.Used + size \u003e capacity.Total {       // snapshot compare only; no lock, no reservation\n        return fs.ErrInsufficientCapacity\n    }\n    return nil\n}\n```\n\n`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`:\n\n```go\nfunc (f *DBFS) Capacity(ctx context.Context, u *ent.User) (*fs.Capacity, error) {\n    ...\n    res.Used  = f.user.Storage            // captured at request start\n    res.Total = requesterGroup.MaxStorage\n    return res, nil\n}\n```\n\nNo SELECT is issued at check time, no row lock is taken on the user row, and pending upload sessions are not counted.\n\n**Stage B — the charge (single unconditional UPDATE, outside the tx)** — `pkg/filemanager/fs/dbfs/upload.go` → `inventory/tx.go` → `inventory/user.go`:\n\n```go\n// PrepareUpload: check (A) ...  then, many statements later ...\nif err := f.validateUserCapacity(ctx, req.Props.Size, ancestor.Owner()); err != nil {\n    return nil, err\n}\n...\nif err := inventory.CommitWithStorageDiff(ctx, dbTx, f.l, f.userClient); err != nil { ... }  // charge (B)\n\n// inventory/user.go\nc.client.User.Update().Where(user.ID(uid)).AddStorage(diff).Exec(ctx)  // SQL: storage = storage + diff\n```\n\nBetween 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`.\n\nThree defensive controls that would each independently close the race are missing:\n\n1. The check and the charge are not enclosed in the same transaction with a `SELECT ... FOR UPDATE` on the user row.\n2. 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 \u003c= :max_storage`.\n3. `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.","status":"published","published":"2026-09-22T20:40:33Z","modified":"2026-10-01T20:55:42.489138466Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H","level":"high"}],"cwes":["CWE-362","CWE-367","CWE-770"],"updated_at":"2026-11-02T15:47:00.198893Z"},{"id":"GO-2026-6578","title":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service in github.com/cloudreve/Cloudreve","description":"Cloudreve: Storage-quota TOCTOU race allows quota bypass and storage-based denial of service in github.com/cloudreve/Cloudreve","status":"published","published":"2026-10-01T20:23:38Z","modified":"2026-10-01T20:45:15.886625594Z","updated_at":"2026-11-02T15:47:03.11707Z"}]}}