Summary

Cloudreve's remote download workflow accepts user-supplied URLs and passes them to the configured downloader without blocking loopback, localhost, IPv6 localhost, or redirect-to-loopback targets.

When the remote download permission is granted to a non-admin user group, a normal authenticated user can make the server-side downloader fetch internal-only URLs and then read the fetched response after it is imported into the user's own Cloudreve files.

This does not affect default normal users unless the remote download permission is enabled for their group. However, the permission is a feature-level user-group capability and does not make the user an administrator.

Attacker requirements

The attacker must be:

- authenticated - non-admin - in a user group where GroupPermissionRemoteDownload is enabled

Default normal users are blocked from the affected workflow. In the default install, only the admin group has the remote download permission, while the default User group does not.

Affected endpoint

http POST /api/v4/workflow/download

Follow-up attacker readback was performed through normal workflow and file APIs:

http GET /api/v4/workflow?category=downloaded... GET /api/v4/file?uri=cloudreve://my... POST /api/v4/file/url

Root cause

The remote download workflow checks whether the user group has remote download permission, but it does not validate the submitted URL before passing it to the downloader.

Relevant code paths:

- service/explorer/workflows.go:81 - pkg/filemanager/workflows/remotedownload.go:202 - pkg/downloader/aria2/aria2.go:56

The application does not block loopback, localhost, IPv6 localhost, or redirect targets resolving to internal addresses.

Impact

A non-admin user with remote download permission can use Cloudreve as an SSRF primitive to access services reachable from the downloader environment.

In my test, the attacker could fetch internal loopback URLs and read the response body after Cloudreve imported the downloaded content into the attacker's own files.

Confirmed targets:

- http://127.0.0.1:7777/secret2 - http://localhost:7777/localsecret - http://[::1]:7780/v6secret - redirect to http://127.0.0.1:7777/redirsecret

This can expose internal HTTP services, loopback-only admin panels, local service metadata, or other network resources that are not directly reachable by the attacker.

Reproduction

1. Permission negative control

The attacker is a normal non-admin user in the default User group.

Before enabling remote download for the group:

http POST /api/v4/workflow/download Content-Type: application/json

{"src":["http://127.0.0.1:7777/secret"],"dst":"cloudreve://my"}

Response:

json {"code":40007,"msg":"Group not allowed to download files"}

2. Enable only remote download permission for the non-admin group

The default install grants remote download to the admin group only. The default User group does not have it.

Confirmed in:

- inventory/migration.go:154 - inventory/migration.go:179

For this test, I only changed group 2 permissions from:

text hAg=

to:

text hAo=

The attacker remained in the User group and was not made admin. GET /api/v4/user/me still returned the group name as User.

3. Start an internal listener

Example listener on the Cloudreve host:

text 127.0.0.1:7777

The listener returned a marker response:

text SSRFSECRET220260527

4. Queue a remote download to loopback

http POST /api/v4/workflow/download Content-Type: application/json

{"src":["http://127.0.0.1:7777/secret2"],"dst":"cloudreve://my"}

Response:

json {"code":0,"data":[{"id":"OzH4","status":"queued","type":"remotedownload"}]}

The internal listener received the request:

text 127.0.0.1 - - [27/May/2026 13:00:46] "GET /secret2 HTTP/1.1" 200 -

Aria2 completed the download:

text Download complete: /home/b4r/cysec/cvehunting/cloudreve/data/temp/.../secret2

5. Read the imported internal response as the attacker

The task completed successfully:

json {"id":"OzH4","status":"completed","summary":{"props":{"srcstr":"http://127.0.0.1:7777/secret2","failed":0}}}

The attacker could list the imported file:

json {"name":"secret2","path":"cloudreve://my/secret2"}

The attacker could then download and read the response body:

text SSRFSECRET220260527

Additional validated variants

localhost

Input:

text http://localhost:7777/localsecret

Attacker readback:

text LOCALHOSTSECRET20260527

Redirect to loopback

Input:

text http://127.0.0.1:7779/anything

Redirect:

text 302 Location: http://127.0.0.1:7777/redirsecret

Attacker readback:

text REDIRSECRET20260527

IPv6 localhost

Input:

text http://[::1]:7780/v6secret

Attacker readback:

text IPV6SECRET20260527

Expected behavior

Cloudreve should reject remote download URLs that resolve to loopback, localhost, private network ranges, link-local ranges, metadata service ranges, or other internal-only targets unless explicitly allowed by an administrator.

Redirect targets should be checked with the same policy.

Actual behavior

Cloudreve accepts the URL, passes it to the downloader, imports the fetched internal response into the attacker's files, and allows the attacker to read it.

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 clientid claim. Later, the JWT verifier only loads scopes into the request context when claims.ClientID != "". Because the OAuth access token has no clientid, 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 implementation makes OAuth access tokens fall into the first category by mistake.

## Affected code

In the OAuth authorization code exchange, Cloudreve passes both ClientID and Scopes into token issuance:

go token, err := tokenAuth.Issue(c, &auth.IssueTokenArgs{ User: user, ClientID: s.ClientID, Scopes: authCode.Scopes, RefreshTTLOverride: refreshTTLOverride, })

Location:

- service/oauth/oauth.go

In Issue(...), the access token includes Scopes but does not include ClientID:

accessToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, Claims{ TokenType: TokenTypeAccess, RegisteredClaims: jwt.RegisteredClaims{ Subject: uidEncoded, NotBefore: jwt.NewNumericDate(issueDate), ExpiresAt: jwt.NewNumericDate(accessTokenExpired), }, Scopes: args.Scopes, }).SignedString(t.secret)

By contrast, the refresh token does include both:

Scopes: args.Scopes, ClientID: args.ClientID,

Location:

- pkg/auth/jwt.go

During request authentication, scopes are only inserted into request context if ClientID is present:

if claims.ClientID != "" { util.WithValue(c, ScopeContextKey{}, claims.Scopes) }

Location:

- pkg/auth/jwt.go

Then CheckScope(...) skips scope enforcement if no scopes are present in context:

hasScopes, tokenScopes := GetScopesFromContext(c) if !hasScopes { return nil }

Location:

- pkg/auth/jwt.go

RequiredScopes(...) relies on this check:

if err := auth.CheckScope(c, requiredScopes...); err != nil { c.JSON(200, serializer.Err(c, err)) c.Abort() return }

Location:

- middleware/auth.go

Sensitive route groups protected by RequiredScopes(...) include:

- Files: Files.Read / Files.Write - Shares: Shares.Read / Shares.Write - Workflows: Workflow.Read / Workflow.Write - User settings and security info - WebDAV device/account management - Admin APIs: Admin.Read / Admin.Write

Location:

- routers/router.go

## Reproduction steps

1. Create or use an OAuth client with a low-privilege scope, for example only openid. 2. Complete the OAuth authorization code flow for a normal user with:

scope=openid

3. Exchange the authorization code via:

POST /api/v4/session/oauth/token

4. Decode the returned access token.

Expected token metadata should preserve enough OAuth client/scope context for later enforcement.

Actual behavior:

- The access token contains the requested scopes. - The access token does not contain clientid.

5. Use the returned token as a bearer token:

Authorization: Bearer <accesstoken>

6. Call an API that requires a scope not granted to the OAuth app, for example an endpoint requiring Files.Read, Files.Write, UserInfo.Write, or DavAccount.Write.

Expected result:

- The request should fail with an insufficient-scope error.

Actual result:

- The scope check is skipped because no scopes were inserted into the request context. - The request is processed as that user.

If the authorizing user is an administrator, the same issue can affect admin APIs requiring Admin.Read or Admin.Write, because the request still runs as the admin user and the admin identity check can pass while the OAuth scope check is skipped.

## Impact

This is not an anonymous authentication bypass. The attacker still needs a valid OAuth access token for a real user.

The impact is an OAuth consent/scope boundary bypass:

- A third-party OAuth app can request a minimal scope such as openid. - After the user authorizes it, the app receives an access token. - That token can be used as a broader bearer token for the same user's Cloudreve account, despite not being granted the required scopes.

For normal users, this may allow access to or modification of files, shares, workflows, user settings, and WebDAV account/device settings depending on available APIs.

For administrator users, it may allow access to admin-scoped functionality without the OAuth app being granted Admin.Read or Admin.Write.

## Suggested fix

1. Include ClientID: args.ClientID in access token claims when issuing OAuth access tokens:

accessToken, err := jwt.NewWithClaims(jwt.SigningMethodHS256, Claims{ TokenType: TokenTypeAccess, RegisteredClaims: jwt.RegisteredClaims{ Subject: uidEncoded, NotBefore: jwt.NewNumericDate(issueDate), ExpiresAt: jwt.NewNumericDate(accessTokenExpired), }, Scopes: args.Scopes, ClientID: args.ClientID, }).SignedString(t.secret)

2. Consider making scope handling fail closed for OAuth tokens with malformed or inconsistent OAuth metadata. 3. Add regression tests for an OAuth access token granted only openid attempting to call APIs requiring: - Files.Read - Files.Write - UserInfo.Write - DavAccount.Write - Admin.Read - Admin.Write

Each should fail with an insufficient-scope error unless the corresponding scope was granted.

Cloudreve versions v1.0.0 through v3.5.3 are vulnerable to Stored Cross-Site Scripting (XSS), via the file upload functionality. A low privileged user will be able to share a file with an admin user, which could lead to privilege escalation.