CVE-2026-77633: Cloudreve Storage Quota Bypass DOS Vulnerability

CVE-2026-77633 Overview

Cloudreve is a self-hosted file management and sharing platform. CVE-2026-77633 is a race condition [CWE-362] in the PrepareUpload function within pkg/filemanager/fs/dbfs/upload.go. The flaw allows an authenticated user with Files.Write permission to bypass per-account storage quotas by issuing concurrent upload-session requests. Each concurrent request reads the same stale in-memory user capacity snapshot, passes the MaxStorage check, and reserves its declared size through CommitWithStorageDiff outside of a single quota-enforcing transaction. The resulting over-reservations can be materialized as chunked uploads that exhaust the underlying host storage. The default local-storage policy and default User group are affected. The issue is fixed in version 4.18.0.

Critical Impact
An authenticated low-privilege user can exhaust host disk capacity, denying uploads to all other Cloudreve users and disrupting service availability.

Affected Products

Cloudreve versions prior to 4.18.0
Deployments using the default local-storage policy
Deployments using the default User group with Files.Write permission

Discovery Timeline

2026-09-22 - CVE-2026-77633 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-77633

Vulnerability Analysis

The vulnerability is a time-of-check to time-of-use (TOCTOU) race condition in Cloudreve's upload preparation flow. PrepareUpload invokes validateUserCapacity, which reads the user's current storage usage from an in-memory snapshot. It then applies a storage charge through CommitWithStorageDiff outside the transaction that enforces the quota. Because the quota check and the storage reservation are not atomic, multiple concurrent upload-session requests observe identical pre-upload capacity values. Every request passes the MaxStorage check simultaneously and each reserves its declared byte count. The sum of these reservations can exceed the configured account quota.

Root Cause

The root cause is the absence of a transactional read-modify-write on the user storage row. The pre-upload capacity check reads a snapshot value, while the compensating storage diff is written outside the quota-enforcing transaction. Without a row-level lock on the users record before any writes to files or entities, concurrent requests for the same owner cannot serialize on the quota decision.

Attack Vector

An authenticated attacker holding Files.Write permission opens multiple upload-session requests in parallel, each declaring a chunk size at or near the remaining quota. All sessions pass validation, reserve their declared sizes, and can be materialized as chunked uploads. The resulting files consume host storage well beyond the account quota and can fill the underlying disk, denying uploads to other users.

// Patch: enforce storage pre-allocation inside the quota transaction
// Source: https://github.com/cloudreve/cloudreve/commit/7329602751c00bb4136fe9ad8b364d0df70773df
func (t *Tx) ReserveStorage(ctx context.Context, uc UserClient, uid int, size, maxTotal int64) error {
    if size <= 0 {
        return nil
    }

    txUc, _ := InheritTx(ctx, uc)
    if err := txUc.ReserveStorage(ctx, uid, size, maxTotal); err != nil {
        // Caller MUST Rollback on failure; placeholder writes done
        // afterwards would otherwise commit without a matching reservation.
        return err
    }
    return nil
}

The patched ReserveStorage API atomically adds size bytes to the user's storage inside the transaction, enforcing storage + size <= maxTotal at the database level. It must be called as the first write of the transaction so the users-row exclusive lock is acquired before any INSERT into files or entities.

Detection Methods for CVE-2026-77633

Indicators of Compromise

Multiple upload-session requests from the same authenticated user account within a short time window targeting the same storage policy.
Sudden growth of the Cloudreve data directory or object store that exceeds the sum of configured user quotas.
Chunked upload sessions where the declared size approaches remaining user quota, initiated concurrently.
Failed upload requests from unrelated users citing insufficient host storage.

Detection Strategies

Instrument the Cloudreve API layer to log the timestamp, user ID, and declared size for every PrepareUpload call and alert on burst patterns per user.
Compare aggregate stored bytes per user against the configured MaxStorage value on a scheduled basis and flag any exceedance.
Monitor host filesystem utilization on the Cloudreve storage volume and alert on abnormal growth rates.

Monitoring Recommendations

Enable database query logging for writes to the users, files, and entities tables and correlate to originating HTTP sessions.
Track HTTP request concurrency per authenticated principal at the reverse proxy or WAF.
Alert when a single account creates more upload sessions per minute than an established baseline.

How to Mitigate CVE-2026-77633

Immediate Actions Required

Upgrade all Cloudreve instances to version 4.18.0 or later, which introduces the transactional ReserveStorage API.
Audit user storage consumption against configured quotas and reconcile any accounts that exceed MaxStorage.
Review the default User group permission set and remove Files.Write from accounts that do not require upload capability.

Patch Information

The fix is delivered in Cloudreve 4.18.0. See the GitHub Release 4.18.0, the GitHub Security Advisory GHSA-xj3h-wwxq-gfcj, and the remediating commit 7329602751c for implementation details.

Workarounds

Apply per-user rate limiting on the PrepareUpload endpoint at a reverse proxy to reduce concurrency.
Enforce filesystem-level quotas on the Cloudreve data directory as a defense-in-depth control against host exhaustion.
Temporarily restrict Files.Write on the default User group until the upgrade is deployed.

bash

# Example: nginx per-user request rate limit for upload preparation
limit_req_zone $http_authorization zone=cloudreve_upload:10m rate=5r/s;

location /api/v4/file/upload {
    limit_req zone=cloudreve_upload burst=10 nodelay;
    proxy_pass http://cloudreve_backend;
}