Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-62683

CVE-2026-62683: File Browser Information Disclosure Bug

CVE-2026-62683 is an information disclosure vulnerability in File Browser that leaves public shares active after directory deletion. This article covers the technical details, affected versions, impact, and mitigation.

Published:

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.

go
// 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
bash
# 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.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.