CVE-2026-62683 Overview
CVE-2026-62683 is an authorization flaw [CWE-863] in File Browser, an open-source web interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Versions prior to 2.63.17 fail to clean up public directory shares when the underlying shared directory is deleted using a path with a trailing slash. The Bolt storage backend performs a database prefix query with the unnormalized path before trimming the slash for boundary checks. As a result, deleting /a/ does not remove the stored /a share record. If an operator later recreates the same path, the stale share silently exposes the new content to unauthenticated visitors.
Critical Impact
Stale public shares can re-expose confidential files when a previously shared directory path is recreated, bypassing operator expectations of share deletion.
Affected Products
- File Browser versions prior to 2.63.17
- Deployments using the Bolt database storage backend
- Instances that permit users to create public directory shares
Discovery Timeline
- 2026-07-15 - CVE-2026-62683 published to the National Vulnerability Database (NVD)
- 2026-07-15 - Last updated in NVD database
Technical Details for CVE-2026-62683
Vulnerability Analysis
The flaw resides in the share cleanup path invoked when a directory is deleted. The handler calls DeleteWithPathPrefix(file.Path, userID) in the Bolt share backend located at storage/bolt/share.go. The function issues a prefix query against the Path index using the raw pathPrefix value it receives from the caller. Only after the query does the code trim a trailing slash to perform boundary checks.
Share records are stored in the database without trailing slashes. When a user deletes a directory whose path ends in /, the prefix query looks for entries beginning with /a/, misses the stored /a record, and returns no matches. The cleanup loop then exits without removing the share. The public share URL remains valid and continues to point at the now-empty directory slot.
Root Cause
The root cause is a path normalization mismatch between share write operations and share delete operations. Writers store paths in canonical form without a trailing slash, while the delete path preserves whatever slash form the caller provided when performing the lookup. This inconsistency creates an improper authorization condition [CWE-863] because deleted-but-unremoved shares continue granting public access to any future data placed at the same logical path.
Attack Vector
Exploitation requires an authenticated File Browser user with permission to create and delete shared directories. The user creates a public share on a directory, deletes it using a trailing-slash path, and later recreates a directory at the same path. Any files placed in the recreated directory become accessible through the original share link without authentication. The scenario is a low-complexity misconfiguration path rather than a direct external attack.
// Patch: storage/bolt/share.go — trim trailing slash BEFORE the prefix query
func (s shareBackend) DeleteWithPathPrefix(pathPrefix string, userID uint) error {
// Share paths are stored without a trailing slash
prefix := strings.TrimRight(pathPrefix, "/")
var links []share.Link
if err := s.db.Prefix("Path", prefix, &links); err != nil {
if errors.Is(err, storm.ErrNotFound) {
return nil
}
return err
}
var err error
for _, link := range links {
if link.UserID != userID {
// ...
}
}
}
Source: File Browser commit f30fca6
Detection Methods for CVE-2026-62683
Indicators of Compromise
- Public share URLs that remain reachable after the administrator has deleted the underlying directory
- Entries in the Bolt shares database whose Path value does not correspond to any current filesystem directory
- HTTP 200 OK responses to /api/public/share/<hash> requests for shares an operator believed were removed
Detection Strategies
- Compare the set of stored share records against the current directory tree and flag orphaned share entries
- Review File Browser audit logs for DELETE operations on directory paths ending with / that were not accompanied by a matching share removal event
- Enumerate the Bolt database using the File Browser CLI to list active shares and validate each one against live filesystem state
Monitoring Recommendations
- Log and alert on external access to public share URLs, particularly for shares older than the associated directory
- Monitor for repeated create-delete-recreate cycles on the same directory path, which increase exposure risk
- Track upgrades of the File Browser binary and confirm all instances run version 2.63.17 or later
How to Mitigate CVE-2026-62683
Immediate Actions Required
- Upgrade File Browser to version 2.63.17 or later on all instances
- Audit the shares database and revoke any public shares whose target directory no longer exists
- Instruct users to remove public shares explicitly before deleting the underlying directory
Patch Information
The fix is included in File Browser release v2.63.17. The corrective change in commit f30fca6 trims the trailing slash from pathPrefix before executing the Bolt Prefix query, ensuring that stored share records without trailing slashes are matched and deleted. See the GitHub Security Advisory GHSA-pp88-jhwj-5qh5 for full advisory details.
Workarounds
- Manually delete each public share through the File Browser UI before removing the underlying directory
- Avoid deleting directories using paths that include a trailing slash on vulnerable versions
- Restrict the ability to create public shares to trusted user roles until the patch is applied
# Verify installed version and upgrade to the patched release
filebrowser version
# Example Docker upgrade
docker pull filebrowser/filebrowser:v2.63.17
docker stop filebrowser && docker rm filebrowser
docker run -d --name filebrowser \
-v /srv/files:/srv \
-v /etc/filebrowser/database.db:/database.db \
-p 8080:80 \
filebrowser/filebrowser:v2.63.17
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

