Cloudreve is a self-hosted file management and sharing system. From 4.12.0 until 4.16.1, Cloudreve's OAuth access tokens are issued without the OAuth client_id claim, so the JWT verifier does not load token scopes into request context and RequiredScopes treats the request like non-scoped session authentication, allowing a low-scope OAuth access token to call APIs requiring higher scopes such as file, share, workflow, user setting, WebDAV account, and potentially admin scopes. This issue is fixed in version 4.16.1.

Affected: Go: github.com/cloudreve/Cloudreve/v4

## 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.…