File Browser: Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path
Description
Filebrowser allows authenticated users to create public shares for non-existent paths, which later expose files placed at those paths.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Filebrowser allows authenticated users to create public shares for non-existent paths, which later expose files placed at those paths.
Vulnerability
In filebrowser versions before 2.63.7, the POST /api/share/ endpoint in http/share.go does not verify that the target path exists before storing a public share record. The sharePostHandler() function checks only authentication and share/download permissions, then creates a share.Link directly from the request path and saves it to the store [1][2]. No Stat or equivalent existence check is performed, so shares can be created for any arbitrary path, regardless of whether a file is currently present.
Exploitation
An attacker must be an authenticated user with share/download permissions. They can craft a POST /api/share/ request targeting a path that does not currently exist, but where a future file may be placed by the owner or another process. The share record is stored with a hash, and the attacker can obtain that hash from the response. Later, when a file is created at the same path by any means, the attacker can access it via GET /api/public/dl/ or GET /api/public/share/ without further authentication [1][2]. No user interaction beyond the attacker's initial request is required.
Impact
Successful exploitation leads to unauthorized public access to files that were created after the share was established. An attacker can read files they would not normally have access to, including sensitive data, by pre-creating shares for paths where future files may appear. The share is bound only to a path string, not to an existing file object, so the disclosure occurs once the path is populated [1][2].
Mitigation
This issue is fixed in filebrowser version 2.63.7, released on 2025-02-03 [3]. The fix adds an existence check using d.user.Fs.Stat(r.URL.Path) before allowing the share creation, rejecting requests for non-existent paths with an appropriate error [4]. Users should upgrade to v2.63.7 or later. No workaround is available for unpatched versions. This vulnerability is not known to be listed in CISA KEV.
AI Insight generated on Jun 12, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1- Range: <= 1.11.0
Patches
1166583db632efix: disallow shares for non-existent paths
1 file changed · +7 −0
http/share.go+7 −0 modified@@ -99,6 +99,13 @@ var shareDeleteHandler = withPermShare(func(_ http.ResponseWriter, r *http.Reque }) var sharePostHandler = withPermShare(func(w http.ResponseWriter, r *http.Request, d *data) (int, error) { + // Only allow sharing paths that currently exist. Otherwise a share could be + // created for a non-existent path and would silently start exposing + // whatever file later appears there. + if _, err := d.user.Fs.Stat(r.URL.Path); err != nil { + return errToStatus(err), err + } + var s *share.Link var body share.CreateBody if r.Body != nil {
Vulnerability mechanics
Root cause
"Missing existence check before creating a public share record allows a share to be bound to a path rather than an existing file, so a future file created at that path is automatically exposed."
Attack vector
An authenticated user with share/download permissions sends a `POST /api/share/<path>` request for a path that does not currently exist. The server creates and stores a public share record without checking whether the file exists. Later, when a file is created at that same path (by any user), the pre-existing share immediately exposes the new file through `GET /api/public/dl/<hash>` [ref_id=1]. This is a classic Time-of-Check-to-Time-of-Use / missing existence validation pattern analogous to CWE-367 but the primary defect is improper access control — the share invariant is broken because the system does not tie the grant to an existing object. [ref_id=2]
Affected code
The vulnerability resides in `http/share.go`'s `sharePostHandler()` (`POST /api/share/<path>`) and in `http/public.go`'s `withHashFile()` (`GET /api/public/dl/<hash>`). The former saves a public share record using `r.URL.Path` without verifying the target file exists; the latter later resolves that stored path against the owner's current filesystem state, meaning a share created for a non-existent path becomes valid as soon as a file appears at that path [ref_id=1].
What the fix does
The patch adds a `d.user.Fs.Stat(r.URL.Path)` call before saving the share record in `sharePostHandler()`. If the file does not exist, `Stat` returns an error and the handler returns immediately with the appropriate HTTP status, never creating the share [patch_id=5749829]. This closes the gap by enforcing that a share can only be created for a path that currently has an existing file, preventing the creation of "future" shares that later become valid.
Preconditions
- authAn attacker must have valid authentication credentials for a user who holds share/download permissions (typically an 'admin' role).
- inputThe attacker must know (or be able to guess) a path that does not currently exist on the server but will later host a file they want to expose.
Reproduction
1. Authenticate to File Browser. 2. Confirm `/future4.txt` does not exist. 3. Create a public share for `/future4.txt` via `POST /api/share/future4.txt`. 4. Confirm the public share returns `404`. 5. Upload a file to `/future4.txt`. 6. Reuse the same public share URL to read the file contents. The reproduction commands are included in the advisory body [ref_id=1].
Generated on Jun 12, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.