Summary
Cloudreve: Privilege Scope Bypass: State-Mutating Admin Operations Accessible via Read-Only OAuth Scope
There is a privilege scope bypass in Cloudreve's admin API where two endpoints that mutate server state are missing the write-scope enforcement that their neighboring endpoints correctly apply. Specifically, the WOPI configuration fetch endpoint and the SMTP test/mail endpoint can both be triggered by an OAuth token that only has Admin.Read authorization, no Admin.Write needed. This breaks the intended OAuth scope boundary in a way that's subtle enough to have slipped through but meaningful enough to matter in a real deployment.
Details
The root cause is an inconsistency in how the admin tool routes are wired up in routers/router.go. The admin route group sets a baseline of ScopeAdminRead for everything underneath it (around line 868), and most write-capable endpoints inside the tool sub-group correctly layer on an additional RequiredScopes(types.ScopeAdminWrite) check on top of that. For example, the thumbnail executable setter (line 929) and the entity URL cache deletion (line 937) both do this properly.
The two endpoints that don't follow this pattern are tool.GET('wopi') (line 925) and tool.POST('mail') (line 933). Despite POST /mail clearly triggering an outbound email and GET /wopi fetching or probing WOPI service connectivity, neither has the ScopeAdminWrite guard. What that means in practice is that any OAuth application granted only Admin.Read, a scope that should be limited to inspecting configuration, not changing anything, can silently invoke both of these operations. The developer looking at the route definitions would reasonably assume all the write-adjacent tool endpoints were protected, because the ones right above and below them are. It's the kind of gap that's easy to miss in a code review.
PoC
# OAuth app with ONLY Admin.Read scope can send emails:
curl -s -X POST -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <ADMIN_READ_ONLY_TOKEN>' \
'https://cloudreve.example.com/api/v4/admin/tool/mail' \
-d '{"settings":{"smtpHost":"smtp.gmail.com","smtpPort":"587",...},"to":"[email protected]"}'
# Expected: 403 Forbidden (if Admin.Write was required)
# Actual: 200 OK, email is sent
Impact
An OAuth application or API key scoped to Admin.Read can send arbitrary emails through the server's configured SMTP account and probe internal WOPI service endpoints, both actions that should require elevated write authorization. In multi-party deployments where Admin.Read tokens are issued more liberally (e.g., to monitoring integrations or third-party plugins), a compromised or malicious token holder gains capabilities well beyond what the scope contract implies. Scope separation in OAuth 2.0 is a security boundary, not just a convention, and its violation here could factor into broader attack chains.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-77637 has a CVSS score of 3.8 (Low). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.0-20260715070110-bce08f88e9d8); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Add middleware.RequiredScopes(types.ScopeAdminWrite) as the first handler argument to both the tool.GET('wopi') and tool.POST('mail') route definitions in routers/router.go. This brings them in line with tool.POST('thumbExecutable') at line 929 and tool.DELETE('entityUrlCache') at line 937, which already follow the correct pattern. No logic changes are needed, it's purely an additive middleware insertion.
If possible, please apply for a CVE number when publishing. I would greatly appreciate it.
Frequently Asked Questions
- What is CVE-2026-77637? CVE-2026-77637 is a low-severity missing authorization vulnerability in github.com/cloudreve/Cloudreve/v4 (go), affecting versions < 4.0.0-20260715070110-bce08f88e9d8. It is fixed in 4.0.0-20260715070110-bce08f88e9d8. The application does not perform an authorization check before performing a sensitive operation.
- How severe is CVE-2026-77637? CVE-2026-77637 has a CVSS score of 3.8 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/cloudreve/Cloudreve/v4 are affected by CVE-2026-77637? github.com/cloudreve/Cloudreve/v4 (go) versions < 4.0.0-20260715070110-bce08f88e9d8 is affected.
- Is there a fix for CVE-2026-77637? Yes. CVE-2026-77637 is fixed in 4.0.0-20260715070110-bce08f88e9d8. Upgrade to this version or later.
- Is CVE-2026-77637 exploitable, and should I be worried? Whether CVE-2026-77637 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-77637 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-77637? Upgrade
github.com/cloudreve/Cloudreve/v4to 4.0.0-20260715070110-bce08f88e9d8 or later.