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

QFinch assessment

## Summary

Technical context

Root cause (verified at 26b6b10) 1. Events route — authenticated, feature-flagged, no share-scope check (routers/router.go): EventHubEnabled defaults true (inventory/setting.go: "fseventpushenabled":"1"). 2. Service subscribes to the listed parent's ID (service/explorer/events.go): 3. Single-file share Root swaps the share root to the owner parent (sharenavigator.go): 4. To returns that parent for the bare root URI (sharenavigator.go): The 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. 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. 6. Publication fans out to ancestor topics with only a client-ID filter (dbfs/events.go): 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. Validation performed Independent validation against commit 26b6b10 in a clean sandbox. 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). 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: - 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. - A model of Root/To/getEligibleSubscriber/relativePath driving the end-to-end flow: Steps to reproduce 1. Owner shares a single file shared.txt from /docs, which also contains Secret-Plan.pdf. 2. Recipient (logged-in, Files.Read, with the share password if any) opens the event stream on the share root: 4. The recipient's stream receives, e.g.: Expected: the recipient only receives events for the shared file. Actual: the recipient receives activity events for unshared siblings in the owner's parent folder. Impact A 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. Remediation - For single-file shares, subscribe to the shared file's ID, or reject event subscriptions on the single-file share root view. - Store an authorization scope (navigator/share root) per subscriber and publish only events whose path stays within that scope. - Incorporate user/share scope into topic keys, not just file ID + client ID. - On subscriber reactivation, re-verify the requester still matches the subscriber and is authorized for the topic.