CVE-2026-77637: Privilege Scope Bypass in Cloudreve Administrative Tools

Cloudreve utilizes Go's Gin framework to structure its application endpoints. Within this layout, the system organizes administrative control features under an 'admin' routing group located in routers/router.go. The routing group establishes a foundational authorization layer by checking for the ScopeAdminRead scope. This scope permits operations associated with viewing the system configuration, user list, and high-level platform diagnostics.

The attack surface consists of the endpoints exposed under the admin namespace, specifically within the sub-routing group admin/tool. These tools allow administrators to perform maintenance, validation, and integration tasks. An architectural failure in scope restriction allowed unprivileged access to these management functions.

This vulnerability, tracked as CVE-2026-77637 or GHSA-w89x-c962-c44g, represents a failure to apply authorization controls to sensitive endpoints. Specifically, the endpoints responsible for fetching Web Application Open Platform Interface configurations and dispatching test emails failed to enforce write-level authorization. Users or API integrations holding read-only administrative tokens could interact with these state-altering operations.

The root cause of CVE-2026-77637 lies in the omission of granular scope checks on nested sub-routes. The parent group admin enforces the read-only administrative scope. However, tasks that perform network requests or expose integration URLs require write-level permissions. In the Cloudreve authorization model, this check is implemented using the middleware.RequiredScopes function with the types.ScopeAdminWrite parameter.

Prior to the patch, the application routing setup did not append this middleware to the handler chains of tool.GET("wopi") and tool.POST("mail"). Since Gin groups inherit middleware from parents, these endpoints only required ScopeAdminRead for access. The lack of explicit write-scope validation meant that any API key or OAuth credential provisioned with read-only administrative access could trigger these actions.

This flaw highlights a structural design risk in manual route decoration. When authorization models require developers to manually add scope checks to every mutating endpoint, the risk of omission remains high. A secure-by-default routing configuration, which applies strict write restrictions to all nested routes unless explicitly exempted, would prevent this class of authorization failure.

The vulnerability exists within the route registration sequence inside the initMasterRouter function in routers/router.go. Analyzing the repository commit history reveals how the endpoints were initially set up without the validation middleware.

Below is the vulnerable configuration for the two endpoints within the nested tool route group:

// Vulnerable Code Path in routers/router.go
tool := admin.Group("tool")
{
    // Endpoint to retrieve Web Application Open Platform Interface settings
    tool.GET("wopi",
        controllers.FromQuery[adminsvc.FetchWOPIDiscoveryService](adminsvc.FetchWOPIDiscoveryParamCtx{}),
        controllers.AdminFetchWopi,
    )
    // Endpoint to send a test email through the SMTP gateway
    tool.POST("mail",
        controllers.FromJSON[adminsvc.TestSMTPService](adminsvc.TestSMTPParamCtx{}),
        controllers.AdminSendTestMail,
    )
}

The corrected implementation in commit bce08f88e9d8f881e78fd18e7a6598b31922c492 inserts the scope-enforcing middleware explicitly before the controller functions are invoked:

// Patched Code Path in routers/router.go
tool := admin.Group("tool")
{
    tool.GET("wopi",
        // Fix: Enforce write privilege scope before calling the controller
        middleware.RequiredScopes(types.ScopeAdminWrite),
        controllers.FromQuery[adminsvc.FetchWOPIDiscoveryService](adminsvc.FetchWOPIDiscoveryParamCtx{}),
        controllers.AdminFetchWopi,
    )
    tool.POST("mail",
        // Fix: Enforce write privilege scope before initiating SMTP connection
        middleware.RequiredScopes(types.ScopeAdminWrite),
        controllers.FromJSON[adminsvc.TestSMTPService](adminsvc.TestSMTPParamCtx{}),
        controllers.AdminSendTestMail,
    )
}

This modification ensures that Gin processes the RequiredScopes middleware first. If the client credentials do not match the required administrative write privileges, the middleware aborts the request chain with an HTTP 403 Forbidden response and prevents access to the controller.

Exploitation of CVE-2026-77637 requires an active administrative session or API credential possessing the Admin.Read scope. An attacker with standard user-level access cannot exploit these routes directly. Once the appropriate credential is secure, the attack proceeds through direct HTTP interaction with the backend routing interface.

In the first scenario, an attacker targets the SMTP testing endpoint /api/v4/admin/tool/mail using a POST request. The request payload contains parameter values for the destination email, SMTP server, port, username, password, and security configuration. The backend receives the payload, bypasses the write authorization check, and commands the server to dispatch an email. This behavior allows attackers to verify internal SMTP configuration details or utilize the server for unauthorized email relaying.

In the second scenario, the attacker targets the WOPI discovery endpoint at /api/v4/admin/tool/wopi using a GET request. The application processes the query, retrieves the configuration, and returns the endpoint metadata associated with online document viewer integrations. This leaks internal network targets and resource paths to the authenticated read-only client.

The security impact of this vulnerability is categorized as low because it requires administrative credentials to exploit. However, in environments utilizing granular delegated permissions or automation accounts, this flaw breaches security compartmentalization. Read-only tokens are often assigned to automated monitoring systems or read-only dashboards, which should not possess execution capabilities.

By exploiting the SMTP testing interface, an attacker can perform outbound spam or phishing campaigns that appear to originate from a trusted domain. Additionally, attackers can use the interface to bruteforce and test SMTP configurations or scan internal mail servers. This capability compromises network reputation and risks domain blacklisting.

Exposing the WOPI details leaks configurations that map internal server URLs and integration architectures. The exposure provides mapping information that an attacker can utilize during the reconnaissance phase of a larger target exploitation sequence.

The primary remediation for this vulnerability is to upgrade Cloudreve to version 4.18.0 or later. This version contains the required routing updates that enforce correct scope boundaries. Software administrators should download and verify the updated release from the official repository.

If upgrading immediately is not possible, administrators should apply defensive network controls. Implement egress firewall rules to restrict outbound SMTP connections from the Cloudreve host, limiting traffic to trusted email relays. This step mitigates the unauthorized utilization of the mail tool.

Conduct a review of all active API keys and OAuth tokens within the platform. Any tokens provisioned with administrative privileges must be audited to ensure that read-only accounts cannot access administrative write-level API paths. Revoke unnecessary or high-privilege keys that do not align with the principle of least privilege.