CVE-2026-62683: Incorrect Authorization via Stale Public Shares in File Browser

File Browser (filebrowser/filebrowser) is an open-source, self-hosted web application written in Go that provides a file management interface for uploading, deleting, previewing, renaming, and sharing files within a designated directory hierarchy. In addition to authenticated user access, the platform supports generating public share links (share.Link) that grant unauthenticated external users read and download access to specific files or directories via unique token hashes.

In versions prior to 2.63.17, File Browser fails to properly revoke public directory shares when the underlying directory is deleted via an HTTP API request containing a trailing slash. This vulnerability is tracked as CVE-2026-62683 (and cross-referenced with GHSA-pp88-jhwj-5qh5 as well as duplicate identifier CVE-2026-61874).

The flaw is classified under CWE-863 (Incorrect Authorization). It originates in the BoltDB storage backend (storage/bolt/share.go), specifically within the DeleteWithPathPrefix method responsible for cascading deletions of share metadata when a filesystem resource is removed. Due to an order-of-operations error in path normalization, deleting a directory such as /a/ cleans up shares for child elements (e.g., /a/file.txt) but leaves the exact parent directory share record (/a) intact in the database.

While the deleted directory no longer exists on disk immediately following the request, the authorization token remains valid in persistent storage. If an authenticated user or automated workflow subsequently creates a new directory at the identical path (/a) and populates it with sensitive files, the pre-existing public share URL immediately resolves to the new directory without requiring the owner's consent or awareness.

File Browser persists application metadata—including user accounts, settings, and public share links—using BoltDB wrapped by the Storm object-relational mapping library (github.com/asdine/storm/v3). Public shares are represented by the share.Link data structure, which binds a unique cryptographic or random Hash to a Path, UserID, and expiration timestamp.

When a public share is created for a directory, File Browser normalizes the target path and stores it in canonical form without a trailing slash (for example, Path: "/confidential"). However, when a user deletes a directory through the web interface or REST API, the HTTP DELETE request routed to /api/resources/ frequently includes a trailing slash to denote a directory resource (e.g., DELETE /api/resources/confidential/).

During the resource deletion lifecycle, the HTTP handler in http/resource.go invokes d.store.Share.DeleteWithPathPrefix(file.Path, d.user.ID) to purge any public shares associated with the deleted resource or its descendants. Prior to version 2.63.17, DeleteWithPathPrefix passed the raw, unnormalized pathPrefix argument directly into Storm's s.db.Prefix("Path", pathPrefix, &links) index query before stripping the trailing slash.

Because s.db.Prefix executes a byte-level lexical prefix scan over the indexed Path field in BoltDB, querying for the prefix "/confidential/" (length 14) cannot match the stored parent record "/confidential" (length 13). The database query only retrieves records whose paths strictly begin with "/confidential/", such as nested files or subdirectories. Although the function subsequently normalized the string via prefix := strings.TrimRight(pathPrefix, "/") to perform in-memory boundary verification, the parent share record was never loaded into the links slice from the database, rendering the post-query normalization ineffective.

The vulnerability resides in storage/bolt/share.go within the DeleteWithPathPrefix method. Examining the vulnerable implementation alongside patch commit f30fca636c1af9ef401e9a82ff60391cb3db97e1 illustrates how the timing of string normalization caused the database query mismatch.

In the vulnerable version, strings.TrimRight(pathPrefix, "/") was executed on line 89, after s.db.Prefix had already queried BoltDB using the unnormalized pathPrefix variable:

// Vulnerable implementation in storage/bolt/share.go (Prior to v2.63.17)
func (s shareBackend) DeleteWithPathPrefix(pathPrefix string, userID uint) error {
	var links []share.Link
	// BUG: pathPrefix still contains the trailing slash (e.g., "/a/").
	// Storm queries BoltDB for keys starting with "/a/", missing "/a".
	if err := s.db.Prefix("Path", pathPrefix, &links); err != nil {
		if errors.Is(err, storm.ErrNotFound) {
			return nil
		}
		return err
	}
 
	// Normalization occurs too late; "/a" was excluded from 'links'.
	prefix := strings.TrimRight(pathPrefix, "/")
 
	var err error
	for _, link := range links {
		if link.UserID != userID {
			continue
		}
 
		if link.Path != prefix && !strings.HasPrefix(link.Path, prefix+"/") {
			continue
		}
 
		if errDb := s.db.DeleteStruct(&link); errDb != nil {
			err = errDb
		}
	}
 
	return err
}

The patch in commit f30fca636c1af9ef401e9a82ff60391cb3db97e1 resolves the issue by moving the strings.TrimRight operation to the beginning of DeleteWithPathPrefix and passing the normalized prefix into s.db.Prefix:

--- a/storage/bolt/share.go
+++ b/storage/bolt/share.go
@@ -78,16 +78,17 @@ func (s shareBackend) Delete(hash string) error {
 }
 
 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", pathPrefix, &links); err != nil {
+	if err := s.db.Prefix("Path", prefix, &links); err != nil {
 		if errors.Is(err, storm.ErrNotFound) {
 			return nil
 		}
 		return err
 	}
 
-	prefix := strings.TrimRight(pathPrefix, "/")
-
 	var err error
 	for _, link := range links {
 		if link.UserID != userID {

Fix Completeness Assessment

Querying BoltDB with the stripped prefix (e.g., "/a") causes s.db.Prefix to return all records starting with the byte sequence "/a", which includes the target directory ("/a"), its descendants ("/a/child.txt"), and any sibling paths sharing the same character prefix ("/abc"). The existing in-memory boundary filter inside the loop (if link.Path != prefix && !strings.HasPrefix(link.Path, prefix+"/")) properly filters out sibling paths like "/abc" while retaining both "/a" and "/a/child.txt" for deletion. Furthermore, link.UserID != userID ensures multi-tenant isolation. The accompanying unit test TestDeleteWithPathPrefixTrailingSlash in storage/bolt/share_test.go verifies that target shares and descendants are deleted while sibling paths and shares belonging to other user IDs remain untouched. The fix is complete for this code path.

Exploiting CVE-2026-62683 requires a specific sequence of state transitions involving an authenticated user creating, sharing, deleting, and subsequently recreating a directory under the same path name. Alternatively, an authenticated attacker with low privileges on a shared File Browser instance can intentionally leave dormant backdoor shares across predictable directory paths.

Exploitation Sequence

1. Share Initialization: An authenticated user (Alice) creates a directory at /confidential and generates a public share link for it via the File Browser API:

POST /api/share/confidential HTTP/1.1
Host: files.example.com
X-Auth: <Alice_JWT_Token>
Content-Type: application/json
 
{"password":"","expires":"0","unit":"days"}

The application stores the share.Link record in BoltDB with Path: "/confidential" and returns a share identifier hash (e.g., abc12345). External users can access the directory at https://files.example.com/share/abc12345.

2. Trailing-Slash Deletion: When the shared directory is no longer needed, Alice (or an automated cleanup script) deletes the directory using a URI containing a trailing slash:

DELETE /api/resources/confidential/ HTTP/1.1
Host: files.example.com
X-Auth: <Alice_JWT_Token>

The server deletes /confidential from the OS filesystem and invokes DeleteWithPathPrefix("/confidential/", aliceID). Because of the prefix mismatch, the share record for "/confidential" (hash abc12345) is not removed from BoltDB. Requests to /share/abc12345 at this stage return a 404 Not Found error because the underlying filesystem path does not exist, making the share appear revoked.

3. Directory Recreation and Exposure: Later, Alice creates a new directory named /confidential to store private files (such as credentials.txt) and does not configure any public shares for it.

4. Unauthorized Retrieval: Because the database record associating hash abc12345 with Path: "/confidential" was never purged, the dormant share immediately binds to the newly created directory. Any unauthenticated party possessing the previously distributed URL (https://files.example.com/share/abc12345) can browse and download credentials.txt:

GET /api/public/dl/abc12345/credentials.txt HTTP/1.1
Host: files.example.com

> [!NOTE] > In a malicious insider or compromised account scenario, an authenticated user can pre-populate hidden public share tokens for common directory names (e.g., /backups/, /exports/, /invoices/), delete those directories with a trailing slash so they disappear from the filesystem, and wait for another process or user sharing the same workspace scope to recreate and populate those directories.

The security impact of CVE-2026-62683 is unauthorized information disclosure limited to recreated directory paths that were previously shared. Both GitHub CNA (for CVE-2026-62683) and VulnCheck CNA (for duplicate CVE-2026-61874) classify this vulnerability as Low severity.

Under CVSS v3.1, the vulnerability receives a base score of 3.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N). Under CVSS v4.0, it receives a base score of 2.3 (CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N).

Technical Impact Breakdown

• Confidentiality (Low): Unauthenticated actors with knowledge of a historical share hash gain read and download access to all files and subdirectories placed inside the recreated directory. They cannot traverse outside the shared directory root or read arbitrary system files.
• Integrity (None): File Browser public share links provide read-only access. An attacker leveraging a stale share cannot upload, modify, or delete files within the exposed directory.
• Availability (None): The flaw does not degrade server performance or lock out legitimate users.
• Attack Complexity (High): Successful exploitation depends on specific preconditions: a directory must have been publicly shared without an expiration timestamp (or within an active expiration window), deleted specifically via a trailing-slash request path, and later recreated at the exact same path.

Threat intelligence metrics align with the high complexity requirement. The Exploit Prediction Scoring System (EPSS) assigns CVE-2026-62683 a score of 0.00315 (0.32%), placing it in the 24.77th percentile, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Software Upgrade

Administrators should upgrade File Browser to version 2.63.17 or later. Version 2.63.17 incorporates commit f30fca636c1af9ef401e9a82ff60391cb3db97e1, which normalizes the path prefix prior to querying BoltDB during resource deletion.

Auditing and Purging Existing Stale Shares

> [!IMPORTANT] > Upgrading the File Browser binary to 2.63.17 prevents new stale shares from being left behind on future deletions, but it does not retroactively purge orphaned share entries that were already left in filebrowser.db while running a vulnerable version.

Administrators upgrading from versions prior to 2.63.17 should audit currently registered shares to ensure no dormant links remain active in the BoltDB database:

1. Log in to the File Browser web interface as an administrator or have users inspect Settings -> Share Management to review all active share links and revoke any unrecognized or obsolete shares.
2. Create a backup of the BoltDB database file (filebrowser.db).
3. Verify that all share.Link entries stored in the database correspond to existing, intentionally shared paths on the filesystem, removing any entries pointing to non-existent directories or directories that should be private.

Workarounds and Reverse Proxy Normalization

For environments where an immediate upgrade of the File Browser binary is not feasible, administrators can implement path normalization at the reverse proxy layer (such as Nginx, Caddy, or Traefik) to strip trailing slashes on HTTP DELETE requests targeting /api/resources/* before forwarding the request upstream, provided the downstream filesystem handler processes the non-trailing-slash path identically.