When 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.
Consequently, 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.
26b6b10)1. Events route — authenticated, feature-flagged, no share-scope check (routers/router.go):
file := v4.Group("file"); file.Use(middleware.RequiredScopes(types.ScopeFilesRead))
file.GET("events",
middleware.LoginRequired(),
middleware.IsFunctionEnabled(func(c *gin.Context) bool { return dep.SettingProvider().EventHubEnabled(c) }),
controllers.FromQuery[explorer.ExplorerEventService](...), controllers.HandleExplorerEventsPush)
EventHubEnabled defaults true (inventory/setting.go: "fs_event_push_enabled":"1").
2. Service subscribes to the listed parent's ID (service/explorer/events.go):
parent, _, err := m.List(c, uri, &manager.ListArgs{Page:0, PageSize:1}) // also runs share validity/password
...
rx, resumed, err := eventHub.Subscribe(c, parent.ID(), requestInfo.ClientID)
3. Single-file share Root swaps the share root to the owner parent (share_navigator.go):
n.shareRoot = newFile(nil, share.Edges.File)
...
if n.shareRoot.Type() == types.FileTypeFile {
n.singleFileShare = true
n.shareRoot = n.shareRoot.Parent // <-- owner-side parent folder
}
4. To returns that parent for the bare root URI (share_navigator.go):
elements := path.Elements()
if len(elements) == 1 && n.singleFileShare { return latestSharedSingleFile(...) } // only when URI names the file
...
return current // current == shareRoot == owner parent folder
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):
func (f *DBFS) getEligibleSubscriber(ctx, file, checkParentPerm) []foundSubscriber {
roots := file.Ancestors()
for _, root := range roots {
subscribers := f.eventHub.GetSubscribers(ctx, root.Model.ID)
subscribers = lo.Filter(subscribers, func(s eventhub.Subscriber, _ int) bool {
return !(requestInfo != nil && s.ID() == requestInfo.ClientID) // ONLY exclude the causing client
})
...
}
}
// emit*: From: subscriber.relativePath(file) // owner-side path of the changed sibling
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.
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:
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.Root/To/getEligibleSubscriber/relativePath driving the end-to-end flow:[1] single-file share root URI -> m.List parent = "docs" (id 10), NOT shared.txt (id 11) -> subscribed to owner parent
[2] owner renames /docs/Secret-Plan.pdf -> client 'attacker' receives: from="/Secret-Plan.pdf" file_id=12 (topic 10)
[3] CONTROL: event caused by attacker's own client id -> suppressed (the only filter)
[4] CONTROL: explicit URI 'shared.txt' -> resolves to file (id 11) -> no sibling events
shared.txt from /docs, which also contains Secret-Plan.pdf.Files.Read, with the share password if any) opens the event stream on the share root:
GET /api/v4/file/events?uri=cloudreve%3A%2F%2F<share-id>%40share
Cookie: cloudreve-session=<recipient-session>
X-Cr-Client-Id: <uuid>
Accept: text/event-stream
Secret-Plan.pdf.event: event
data: {"type":"rename","file_id":"<hashed>","from":"/Secret-Plan.pdf","to":"/Secret-Plan-v2.pdf"}
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.
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.
| Software | From | Fixed in |
|---|---|---|
github.com/cloudreve/Cloudreve/v4
|
- | 4.0.0-20260613030215-0b00dd308f13 |
github.com/cloudreve/Cloudreve/v3
|
- | 3.0.0-20250225100611-da4e44b77af4.x |
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.