CVE-2026-62683: File Browser · Trailing-slash directory deletion leaves public shares active for recreated paths
Affects github.com/filebrowser/filebrowser/v2Source GCVE Database
Not known to be exploited · CVSS 3.1 Low : upgrade to 2.63.17 when convenient.
Data as of 14 Nov 2026, 01:05 UTC
- Patch
- Available – fixed in 2.63.17
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:NExploitation evidence
Disclosed: evidence found.
CVE published 13 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 13 Nov 2026.
What to do
Upgrade github.com/filebrowser/filebrowser/v2 to 2.63.17.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Gogithub.com/filebrowser/filebrowser/v2 | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
## Summary File Browser v2.63.15 can leave a public directory share behind when the shared directory is deleted through a path with a trailing slash. The share cleanup path calls `DeleteWithPathPrefix(file.Path, userID)`, but the Bolt backend performs the database prefix query with the unnormalized argument before trimming the slash for boundary checks. For a stored share at `/a`, deleting `/a/` queries for paths prefixed by `/a/`, so the exact `/a` share is never loaded and never deleted. If a directory with the same path is later recreated, the stale public share becomes active again and exposes the new directory contents through the old public URL. ## Impact An authenticated user with share, download, and delete permissions can create a valid public share, delete the shared path with a trailing slash, and leave the public link in storage. The link is dormant while the path does not exist, but it exposes future content if the same path is recreated later. The final data exposure is unauthenticated through the public share URL. This bypasses the intended lifecycle cleanup around public shares and is adjacent to the recent public-share path-existence and prefix-boundary fixes. ## Reproduction The following test was run against v2.63.15, commit `be23ab3a15bf957928ecfed88de5ab67850c1b9c`. 1. Create a scoped user with share, download, and delete permissions. 2. Create `/a/old.txt` in that user's scope. 3. Store a valid public share row with `Hash: "h"`, `UserID: 1`, and `Path: "/a"`. 4. Send an authenticated delete request for `/a/` through the resource delete handler. 5. Confirm the directory is deleted. 6. Confirm share hash `h` still exists in storage. 7. Recreate `/a/future.txt`. 8. Request the public share handler at `h/` and observe that the unauthenticated response includes `future.txt`. Command used for the local proof: ```bash go test ./http -run TestValidationTrailingSlashDeleteLeavesExactDirectoryShare -count=1 -v ``` Observed result: ```text === RUN TestValidationTrailingSlashDeleteLeavesExactDirectoryShare --- PASS: TestValidationTrailingSlashDeleteLeavesExactDirectoryShare (0.03s) PASS ok github.com/filebrowser/filebrowser/v2/http 0.044s ``` ## Root cause `storage/bolt/share.go` queries the share index before normalizing the path: ```go func (s shareBackend) DeleteWithPathPrefix(pathPrefix string, userID uint) error { var links []share.Link if err := s.db.Prefix("Path", pathPrefix, &links); err != nil { ... } prefix := strings.TrimRight(pathPrefix, "/") for _, link := range links { if link.UserID != userID { continue } if link.Path != prefix && !strings.HasPrefix(link.Path, prefix+"/") { continue } ... } } ``` For `pathPrefix == "/a/"`, the database prefix query can return descendants such as `/a/child`, but it does not return the exact share path `/a`. The later `TrimRight` cannot delete the exact share because that row was not loaded from storage. `http/resource.go` passes the request-derived path into this cleanup before removing the resource: ```go file, err := files.NewFileInfo(... Path: r.URL.Path ...) ... err = d.store.Share.DeleteWithPathPrefix(file.Path, d.user.ID) ... return d.user.Fs.RemoveAll(r.URL.Path) ``` A request for `/a/` therefore removes the directory but misses the exact `/a` share row. ## Remediation Normalize the path before querying the share index, and cover both the exact normalized path and its descendants. Add regression tests where a stored share path `/a` is removed by `DeleteWithPathPrefix("/a/", userID)` and where `DELETE /api/resources/a/` deletes the exact public share row. Fixed in version 2.63.17.
References
- github.com/filebrowser/filebrowser/security/advisories/GHSA-pp88-jhwj-5qh5 (opens in a new tab)
- github.com/filebrowser/filebrowser/commit/f30fca636c1af9ef401e9a82ff60391cb3db97e1 (opens in a new tab)
- github.com/filebrowser/filebrowser (opens in a new tab)
- github.com/filebrowser/filebrowser/releases/tag/v2.63.17 (opens in a new tab)
- nvd.nist.gov/vuln/detail/cve-2026-62683 (opens in a new tab)