GHSA-vgj4-345g-jcf8

Summary

Cloudreve's OAuth access tokens can bypass OAuth scope enforcement.

This does not appear to be the intended design. The documentation describes OAuth client permissions/scopes, the API has an insufficient-scope error code, and the code comments say RequiredScopes(...) should verify scopes when a token has scopes, while skipping checks only for non-scoped session-based authentication.

However, OAuth access tokens are issued without the OAuth client_id claim. Later, the JWT verifier only loads scopes into the request context when claims.ClientID != "". Because the OAuth access token has no client_id, its scopes are not loaded, and RequiredScopes(...) treats the request like a non-scoped first-party/session token and skips scope checks.

As a result, a low-scope OAuth access token, for example one granted only openid, can call APIs requiring higher scopes such as file, share, workflow, user setting, WebDAV account, and potentially admin scopes when the authorizing user is an administrator.

Why this seems unintended

Cloudreve appears to have an explicit OAuth scope model:

1. The official docs describe OAuth client permissions/scopes and require the authorization request to include requested scopes.
2. The API error code list includes an OAuth insufficient-scope error.
3. RequiredScopes(...) is used across sensitive API groups such as files, shares, workflows, user settings, WebDAV devices, and admin APIs.
4. The middleware comment says scope checks are skipped only when hasScopes is false, for example session-based authentication.
5. Default OAuth clients created during migration explicitly list scopes such as Files.Write, Workflow.Write, and Shares.Write.

This suggests the intended design is:

• First-party/session tokens may be non-scoped and skip OAuth scope checks.
• OAuth access tokens should carry scope metadata and be checked against RequiredScopes(...).

The current...