GHSA-W89X-C962-C44G
Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40Summary
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":"victim@example.com"}'
# 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.
Fix
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-20260715070110-bce08f88e9d8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77637"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:40:35Z",
"nvd_published_at": "2026-09-22T16:17:55Z",
"severity": "LOW"
},
"details": "### Summary\nThere is a privilege scope bypass in Cloudreve\u0027s 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 \u2014 no Admin.Write needed. This breaks the intended OAuth scope boundary in a way that\u0027s subtle enough to have slipped through but meaningful enough to matter in a real deployment.\n\n### Details\nThe 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.\n\nThe two endpoints that don\u0027t follow this pattern are `tool.GET(\u0027wopi\u0027)` (line 925) and `tool.POST(\u0027mail\u0027)` (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 \u2014 a scope that should be limited to inspecting configuration, not changing anything \u2014 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\u0027s the kind of gap that\u0027s easy to miss in a code review.\n\n### PoC\n```bash\n# OAuth app with ONLY Admin.Read scope can send emails:\ncurl -s -X POST -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cADMIN_READ_ONLY_TOKEN\u003e\u0027 \\\n \u0027https://cloudreve.example.com/api/v4/admin/tool/mail\u0027 \\\n -d \u0027{\"settings\":{\"smtpHost\":\"smtp.gmail.com\",\"smtpPort\":\"587\",...},\"to\":\"victim@example.com\"}\u0027\n# Expected: 403 Forbidden (if Admin.Write was required)\n# Actual: 200 OK, email is sent\n```\n\n### Impact\nAn OAuth application or API key scoped to Admin.Read can send arbitrary emails through the server\u0027s configured SMTP account and probe internal WOPI service endpoints \u2014 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.\n\n### Fix\nAdd `middleware.RequiredScopes(types.ScopeAdminWrite)` as the first handler argument to both the `tool.GET(\u0027wopi\u0027)` and `tool.POST(\u0027mail\u0027)` route definitions in `routers/router.go`. This brings them in line with `tool.POST(\u0027thumbExecutable\u0027)` at line 929 and `tool.DELETE(\u0027entityUrlCache\u0027)` at line 937, which already follow the correct pattern. No logic changes are needed \u2014 it\u0027s purely an additive middleware insertion.\n\n**If possible, please apply for a CVE number when publishing. I would greatly appreciate it.**",
"id": "GHSA-w89x-c962-c44g",
"modified": "2026-09-22T20:40:35Z",
"published": "2026-09-22T20:40:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-w89x-c962-c44g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77637"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/bce08f88e9d8f881e78fd18e7a6598b31922c492"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/releases/tag/4.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cloudreve: Privilege Scope Bypass: State-Mutating Admin Operations Accessible via Read-Only OAuth Scope"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.