CVE-2026-54560 Overview
Cloudreve is a self-hosted file management and sharing system used to store, share, and manage files across teams. CVE-2026-54560 is a broken authorization vulnerability [CWE-863] affecting Cloudreve versions from 4.12.0 up to but not including 4.16.1. The flaw stems from OAuth access tokens being issued without the client_id claim. As a result, the JWT verifier does not load token scopes into the request context, and the RequiredScopes middleware treats the request as non-scoped session authentication. A low-scope OAuth token can therefore call APIs requiring higher scopes, including file, share, workflow, user setting, WebDAV account, and potentially admin endpoints.
Critical Impact
A low-privilege OAuth client can escalate its effective permissions and access file, share, workflow, WebDAV, and potentially admin APIs on affected Cloudreve instances.
Affected Products
- Cloudreve versions 4.12.0 through 4.16.0
- Self-hosted Cloudreve deployments exposing OAuth-based API access
- Fixed in Cloudreve 4.16.1
Discovery Timeline
- 2026-07-15 - CVE-2026-54560 published to NVD
- 2026-07-15 - Last updated in NVD database
Technical Details for CVE-2026-54560
Vulnerability Analysis
Cloudreve uses signed JSON Web Tokens (JWT) to represent OAuth access tokens. The verifier is responsible for reading token claims, populating scope metadata into the request context, and letting downstream middleware such as RequiredScopes enforce per-endpoint authorization.
Because access tokens were issued without a client_id claim, the verifier could not distinguish an OAuth-issued token from a standard user session token. When the token reached RequiredScopes, the middleware fell back to the non-scoped session authentication path and skipped scope evaluation entirely. Any endpoint that relies on scope checks — including file, share, workflow, user setting, WebDAV account, and potentially admin routes — could be reached with a token issued for a narrower purpose.
Root Cause
The defect is a missing claim in the JWT builder inside pkg/auth/jwt.go. The access token structure included Scopes but omitted ClientID. The scope enforcement middleware treated the absence of the client identifier as a signal that the request was not an OAuth call, and therefore did not apply scope-based authorization.
Attack Vector
An attacker must first hold a valid low-scope OAuth access token, obtained through a legitimate OAuth authorization flow with the target Cloudreve instance. Using that token, the attacker sends HTTP requests to higher-privilege API endpoints that should be gated by RequiredScopes. The verifier accepts the token, the scope check is bypassed, and the requested action is performed with the authenticated user's underlying permissions.
// Security patch in pkg/auth/jwt.go
// fix(oauth): scope limitation does not take effects in jwt
NotBefore: jwt.NewNumericDate(issueDate),
ExpiresAt: jwt.NewNumericDate(accessTokenExpired),
},
- Scopes: args.Scopes,
+ ClientID: args.ClientID,
+ Scopes: args.Scopes,
}).SignedString(t.secret)
if err != nil {
return nil, fmt.Errorf("faield to sign access token: %w", err)
Source: Cloudreve commit ed20843. The patch adds the ClientID claim so the verifier recognizes OAuth tokens and loads their scopes into the request context.
Detection Methods for CVE-2026-54560
Indicators of Compromise
- OAuth access tokens missing the client_id claim when decoded from Cloudreve API traffic.
- Successful HTTP 200 responses to file, share, workflow, WebDAV, or admin endpoints from sessions authenticated with a narrowly scoped OAuth client.
- API activity from an OAuth client that touches resources unrelated to the client's registered purpose.
Detection Strategies
- Inspect Cloudreve access logs for requests to privileged endpoints where the caller authenticated via OAuth rather than an interactive session.
- Correlate OAuth client identifiers with the set of endpoints they invoke and alert on deviations from expected scopes.
- Decode JWTs captured from HTTP Authorization: Bearer headers and flag tokens issued by vulnerable versions that lack a client_id claim.
Monitoring Recommendations
- Enable verbose HTTP access logging on the Cloudreve reverse proxy and forward logs to a centralized analytics platform.
- Track the Cloudreve build version in asset inventories to identify hosts still running 4.12.0 through 4.16.0.
- Alert on new or unusual OAuth client registrations and on tokens with long lifetimes that access sensitive routes.
How to Mitigate CVE-2026-54560
Immediate Actions Required
- Upgrade all Cloudreve instances to version 4.16.1 or later.
- Revoke existing OAuth access tokens issued by vulnerable builds so they cannot be replayed against the patched verifier.
- Audit OAuth client registrations and remove clients that are unused or over-privileged.
- Review recent API activity from OAuth clients for access to file, share, workflow, WebDAV, or admin endpoints beyond their intended scope.
Patch Information
The issue is fixed in Cloudreve 4.16.1. Details are available in the GitHub Security Advisory GHSA-vgj4-345g-jcf8 and the Cloudreve 4.16.1 release notes. The corrective change is applied in commit ed20843, which adds the ClientID claim to issued access tokens.
Workarounds
- If immediate upgrade is not possible, disable OAuth-based API access until the patched version is deployed.
- Restrict Cloudreve API endpoints to trusted networks using a reverse proxy or firewall.
- Reduce OAuth access token lifetimes to limit the exposure window of previously issued tokens.
# Upgrade Cloudreve to the patched release
wget https://github.com/cloudreve/cloudreve/releases/download/4.16.1/cloudreve.tar.gz
tar -xzf cloudreve.tar.gz
systemctl stop cloudreve
cp cloudreve /usr/local/bin/cloudreve
systemctl start cloudreve
cloudreve --version # verify 4.16.1 or later
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

