CVE-2026-55499: Cloudreve Broken Access Control Vulnerability
MODERATECVE-2026-55499 is a MODERATE (CVSS 4.3) broken access control vulnerability (CWE-863: Incorrect Authorization) affecting Cloudreve libraries in the Go ecosystem. The issue involves broken access control in file event stream: a single-file share recipient is subscribed to the owner's parent folder and receives activity events for unshared siblings. Remediation is available by upgrading affected packages to version 4.0.0-20260613030215-0b00dd308f13.
CVE-2026-55499 at a Glance
Security Impact
CVSS: 4.3
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
How to Fix CVE-2026-55499
To remediate this vulnerability, upgrade all affected Cloudreve dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade github.com/cloudreve/Cloudreve/v4 to 4.0.0-20260613030215-0b00dd308f13
Upgrade github.com/cloudreve/Cloudreve/v3 to Latest secure release
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for github.com/cloudreve/Cloudreve/v4
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-55499, inspect your project dependencies for Cloudreve:
inspect dependencies for github.com/cloudreve/Cloudreve/v4
Analyze the terminal output to locate any version of Cloudreve in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.0.0-20260613030215-0b00dd308f13), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In Cloudreve, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-55499 Affected Cloudreve Versions
2 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
github.com/cloudreve/Cloudreve/v4
|
Go |
< 4.0.0-20260613030215-0b00dd308f13
|
4.0.0-20260613030215-0b00dd308f13
|
|
github.com/cloudreve/Cloudreve/v3
|
Go |
≤ 3.0.0-20250225100611-da4e44b77af4
|
|
References
Frequently Asked Questions
What is CVE-2026-55499?
Which Cloudreve versions are affected?
What version fixes CVE-2026-55499?
Is github.com/cloudreve/Cloudreve/v4 affected?
Is github.com/cloudreve/Cloudreve/v3 affected?
What is the CVSS score of CVE-2026-55499?
What CWE is associated with CVE-2026-55499?
How can I check Go dependencies for CVE-2026-55499?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-w8x7-h2px-xmq8",
"modified" : "2026-07-24T20:49:02Z",
"published" : "2026-07-24T20:49:02Z",
"aliases" : [ "CVE-2026-55499" ],
"summary" : "Cloudreve: Broken Access Control in file event stream: a single-file share recipient is subscribed to the owner's parent folder and receives activity events for unshared siblings",
"details" : "## Summary\n \nWhen an authenticated recipient of a **single-file** share opens the file event stream (`GET /api/v4/file/events?uri=<share-root>`), Cloudreve validates the URI by listing it and then subscribes the caller to `parent.ID()`. For a single-file share, the share navigator resolves the bare share-root URI to the **owner-side parent folder** of the shared file (not the file), while the visible listing is filtered down to just the shared file. The event hub then keys topics by numeric file ID only and, on each file change, fans the event out to subscribers of **every ancestor topic**, filtering only the client ID that caused the event — never the subscriber's share scope.\n \nConsequently, a recipient of one shared file can receive Server-Sent Events (type, sibling path/name, rename target, hashed file ID) for other files and subfolders in the owner's parent folder that were never shared. Contents are not disclosed; file-activity metadata is.\n\n### Details\n## Root cause (verified at `26b6b10`)\n \n**1. Events route — authenticated, feature-flagged, no share-scope check** (`routers/router.go`):\n```go\nfile := v4.Group(\"file\"); file.Use(middleware.RequiredScopes(types.ScopeFilesRead))\nfile.GET(\"events\",\n middleware.LoginRequired(),\n middleware.IsFunctionEnabled(func(c *gin.Context) bool { return dep.SettingProvider().EventHubEnabled(c) }),\n controllers.FromQuery[explorer.ExplorerEventService](...), controllers.HandleExplorerEventsPush)\n```\n`EventHubEnabled` defaults `true` (`inventory/setting.go: \"fs_event_push_enabled\":\"1\"`).\n \n**2. Service subscribes to the listed parent's ID** (`service/explorer/events.go`):\n```go\nparent, _, err := m.List(c, uri, &manager.ListArgs{Page:0, PageSize:1}) // also runs share validity/password\n...\nrx, resumed, err := eventHub.Subscribe(c, parent.ID(), requestInfo.ClientID)\n```\n \n**3. Single-file share `Root` swaps the share root to the owner parent** (`share_navigator.go`):\n```go\nn.shareRoot = newFile(nil, share.Edges.File)\n...\nif n.shareRoot.Type() == types.FileTypeFile {\n n.singleFileShare = true\n n.shareRoot = n.shareRoot.Parent // <-- owner-side parent folder\n}\n```\n \n**4. `To` returns that parent for the bare root URI** (`share_navigator.go`):\n```go\nelements := path.Elements()\nif len(elements) == 1 && n.singleFileShare { return latestSharedSingleFile(...) } // only when URI names the file\n...\nreturn current // current == shareRoot == owner parent folder\n```\nThe bare root share URI has **zero** path elements (`URI.Elements()` returns nil for path `/`), so the `len(elements)==1` guard is skipped and `To` returns the parent folder. `dbfs.List` returns that as `parent`, so `parent.ID()` is the owner parent folder's real ID.\n \n**5. `Children` masks the broader parent** — for `singleFileShare` it returns only `[]*File{sharedFile}`, so the recipient's listing shows just the shared file even though the subscribed topic is the whole parent.\n \n**6. Publication fans out to ancestor topics with only a client-ID filter** (`dbfs/events.go`):\n```go\nfunc (f *DBFS) getEligibleSubscriber(ctx, file, checkParentPerm) []foundSubscriber {\n roots := file.Ancestors()\n for _, root := range roots {\n subscribers := f.eventHub.GetSubscribers(ctx, root.Model.ID)\n subscribers = lo.Filter(subscribers, func(s eventhub.Subscriber, _ int) bool {\n return !(requestInfo != nil && s.ID() == requestInfo.ClientID) // ONLY exclude the causing client\n })\n ...\n }\n}\n// emit*: From: subscriber.relativePath(file) // owner-side path of the changed sibling\n```\n`relativePath` trims the changed file's owner path by the subscribed root's owner path, yielding the sibling's name (e.g. `/Secret-Plan.pdf`). No check that the subscriber is authorized for the changed file or within their share scope.\n \n## Validation performed\n \nIndependent validation against commit `26b6b10` in a clean sandbox.\n \n**Source-verified (static):** all of (1)–(6) confirmed verbatim, including the negative direction (an explicit `…/shared.txt` URI resolves to the file, and `oss`/`qiniu`-style flows are irrelevant here).\n \n**Dynamic (control-flow executed):** the full binary is not buildable offline (modules behind an unreachable proxy, embedded frontend, DB/eventhub). The reseacher ran two harnesses:\n- A `net/url`-based check of the linchpin — the bare root share URI yields `0` path elements (so `To` returns the parent), while `…/shared.txt` yields `1` (returns the file). This is the subtle point on which the whole finding turns, and it holds.\n- A model of `Root`/`To`/`getEligibleSubscriber`/`relativePath` driving the end-to-end flow:\n```\n[1] single-file share root URI -> m.List parent = \"docs\" (id 10), NOT shared.txt (id 11) -> subscribed to owner parent\n[2] owner renames /docs/Secret-Plan.pdf -> client 'attacker' receives: from=\"/Secret-Plan.pdf\" file_id=12 (topic 10)\n[3] CONTROL: event caused by attacker's own client id -> suppressed (the only filter)\n[4] CONTROL: explicit URI 'shared.txt' -> resolves to file (id 11) -> no sibling events\n```\n\n## Steps to reproduce\n \n1. Owner shares a single file `shared.txt` from `/docs`, which also contains `Secret-Plan.pdf`.\n2. Recipient (logged-in, `Files.Read`, with the share password if any) opens the event stream on the share root:\n ```\n GET /api/v4/file/events?uri=cloudreve%3A%2F%2F<share-id>%40share\n Cookie: cloudreve-session=<recipient-session>\n X-Cr-Client-Id: <uuid>\n Accept: text/event-stream\n ```\n3. Owner creates/renames/modifies/moves/deletes `Secret-Plan.pdf`.\n4. The recipient's stream receives, e.g.:\n ```\n event: event\n data: {\"type\":\"rename\",\"file_id\":\"<hashed>\",\"from\":\"/Secret-Plan.pdf\",\"to\":\"/Secret-Plan-v2.pdf\"}\n ```\n \n**Expected:** the recipient only receives events for the shared file.\n**Actual:** the recipient receives activity events for unshared siblings in the owner's parent folder.\n \n## Impact\n \nA single-file share recipient gains a real-time feed of file-activity metadata for the owner's parent folder — sibling names, operation types, and rename targets they were never granted access to. No file contents are exposed.\n \n## Remediation\n \n- For single-file shares, subscribe to the shared file's ID, or reject event subscriptions on the single-file share root view.\n- Store an authorization scope (navigator/share root) per subscriber and publish only events whose path stays within that scope.\n- Incorporate user/share scope into topic keys, not just file ID + client ID.\n- On subscriber reactivation, re-verify the requester still matches the subscriber and is authorized for the topic.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Go",
"name" : "github.com/cloudreve/Cloudreve/v4"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "4.0.0-20260613030215-0b00dd308f13"
} ]
} ]
}, {
"package" : {
"ecosystem" : "Go",
"name" : "github.com/cloudreve/Cloudreve/v3"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"last_affected" : "3.0.0-20250225100611-da4e44b77af4"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-w8x7-h2px-xmq8"
}, {
"type" : "WEB",
"url" : "https://github.com/cloudreve/cloudreve/commit/0b00dd308f132d6e6e8476857ef79f4865600bbc"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/cloudreve/cloudreve"
}, {
"type" : "WEB",
"url" : "https://github.com/cloudreve/cloudreve/releases/tag/4.17.0"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-863" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-24T20:49:02Z",
"nvd_published_at" : null
}
}