CVE-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 ===