Kestrel
대시보드로 돌아가기
CVE-2026-77633HIGH· 7.1MITRENVDGHSA대응게시일: 2026. 09. 22.수정일: 2026. 09. 22.

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

DoS

위협 신호 · CVSS · EPSS · KEV

정기 패치· 높은 악용 신호 없음
CVSS
7.1high

이론적 심각도 점수

EPSS

예측 데이터 없음

KEV
미등재

실측 악용 기록 없음

권장 대응 기한60일 이내CISA SSVC 기준

계획된 패치 주기 내 조치(60일 이내)

외부 노출· KEV 미등재 · 자동화 어려움 · 부분 영향 · 외부 노출

CVSS 벡터 · 메트릭

악용 경로
공격 벡터네트워크
공격 복잡도낮음
필요 권한낮음
사용자 상호작용불필요
범위불변
영향
기밀성 영향없음
무결성 영향낮음
가용성 영향높음
버전별 점수
CVSS 3.17.1HIGH
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:

text
1func (f *DBFS) validateUserCapacity(ctx context.Context, size int64, u *ent.User) error {
2 capacity, err := f.Capacity(ctx, u) // reads "used"
3 if err != nil { return ... }
4 return f.validateUserCapacityRaw(ctx, size, capacity)
5}
6
7func (f *DBFS) validateUserCapacityRaw(ctx context.Context, size int64, capacity *fs.Capacity) error {
8 if capacity.Used + size > capacity.Total { // snapshot compare only; no lock, no reservation
9 return fs.ErrInsufficientCapacity
10 }
11 return nil
12}

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:

text
1func (f *DBFS) Capacity(ctx context.Context, u *ent.User) (*fs.Capacity, error) {
2 ...
3 res.Used = f.user.Storage // captured at request start
4 res.Total = requesterGroup.MaxStorage
5 return res, nil
6}

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.goinventory/tx.goinventory/user.go:

sql
1// PrepareUpload: check (A) ... then, many statements later ...
2if err := f.validateUserCapacity(ctx, req.Props.Size, ancestor.Owner()); err != nil {
3 return nil, err
4}
5...
6if err := inventory.CommitWithStorageDiff(ctx, dbTx, f.l, f.userClient); err != nil { ... } // charge (B)
7
8// inventory/user.go
9c.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.

AI 심층 분석

공격 시나리오 · 재현 가능한 PoC 페이로드 · 즉시 적용 가능한 차단 패치를 한 번에 받아 보세요. 보안 운영팀이 그대로 점검·티켓팅에 쓸 수 있는 형태로 정리해 드립니다.