GITHUB.COM/FILEBROWSER/FILEBROWSER/V2 · CVE-2026-62683 · Package
FIX → 2.63.17
Deleting a shared directory through a path with a trailing slash leaves its public share link stored in the database. If a directory with the same path is later recreated, the old public URL serves the new contents without authentication.
first public Jun 28, 2026 · 2 sources
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Deployments of File Browser v2 below 2.63.17 where users have share, download and delete permissions. The exposure needs an authenticated user who creates a public share, deletes the shared directory with a trailing slash, and later recreates the same path; the share is then reachable without login. Instances where users cannot create public shares are not exposed.
Not affected if no-public-shares, no-share-permission, version-2.63.17-or-later
Who cares file-browser, go, self-hosted
filebrowser version or the image tag; affected builds are below 2.63.17.Upgrade to 2.63.17
2.63.17.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.
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.
The following test was run against v2.63.15, commit be23ab3a15bf957928ecfed88de5ab67850c1b9c.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.
/a/old.txt in that user's scope.Hash: "h", UserID: 1, and Path: "/a"./a/ through the resource delete handler.h still exists in storage./a/future.txt.h/ and observe that the unauthenticated response includes future.txt.Command used for the local proof:
go test ./http -run TestValidationTrailingSlashDeleteLeavesExactDirectoryShare -count=1 -v
Observed result:
=== RUN TestValidationTrailingSlashDeleteLeavesExactDirectoryShare
--- PASS: TestValidationTrailingSlashDeleteLeavesExactDirectoryShare (0.03s)
PASS
ok github.com/filebrowser/filebrowser/v2/http 0.044s
storage/bolt/share.go queries the share index before normalizing the path:
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:
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.
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.
This page as .md · .json · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.