File Browser: Trailing-slash directory deletion leaves public shares active for recreated pathsCVE-2026-62683

## 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.

Quoted source text, attributed separately from HOL analysis.