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

CVE-2026-62685: File Browser Auth Bypass Vulnerability

CVE-2026-62685 is an authentication bypass flaw in File Browser that allows attackers to access other users' files through username normalization. This post covers the technical details, affected versions, and mitigation.

Published:

CVE-2026-62685 Overview

CVE-2026-62685 is a business logic flaw in File Browser, an open-source web interface for managing files within a specified directory. Versions prior to 2.63.17 derive per-user home directories from usernames processed through the cleanUsername() function. The normalization is many-to-one, meaning distinct usernames such as team/one, team one, and team-one collapse to the same scope. When both Signup=true and CreateUserDir=true are configured, a second registrant can claim a username that normalizes to an existing user's directory and receive full read and write access to that user's files. The vulnerability is tracked under [CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions].

Critical Impact

Unauthenticated attackers can register accounts whose normalized scope collides with an existing user, obtaining full read and write access to another user's files.

Affected Products

  • File Browser (filebrowser/filebrowser) versions prior to 2.63.17
  • Deployments with Signup=true and CreateUserDir=true enabled
  • Self-hosted File Browser instances exposing signup to untrusted users

Discovery Timeline

Technical Details for CVE-2026-62685

Vulnerability Analysis

File Browser assigns each new user a scope that becomes their home directory root. When CreateUserDir is enabled, the scope is derived from the username through cleanUsername(), which strips path separators, spaces, and other characters to produce a filesystem-safe identifier. This transformation is not injective. Multiple distinct usernames map to the same normalized value.

The pre-patch signup handler stored the derived scope on the user record and persisted the account without checking whether another user already owned that scope. As a result, an attacker who registered a colliding username inherited the on-disk directory of the earlier registrant. Both accounts then read and wrote the same underlying files through their respective sessions.

Root Cause

The root cause is missing uniqueness validation on a derived authorization key. The username field is unique, but the scope field, which drives file access decisions, is not enforced as unique when generated from the username. This is a canonical [CWE-647] pattern where authorization uses a value that is not the canonical identifier.

Attack Vector

The attack requires network access to an instance where public signup is enabled and per-user directories are provisioned. An attacker enumerates or guesses a target username, then registers a variant that normalizes to the same scope. On successful signup, the attacker logs in and accesses the victim's files through the shared home directory.

go
// Patch: http/auth.go — reject signup when normalized home dir collides
// Source: https://github.com/filebrowser/filebrowser/commit/883a36f02fcb69566a8628cb47f18fdc73348387

		return http.StatusInternalServerError, err
	}
	user.Scope = userHome

	// When home directories are created from the username, distinct usernames
	// can normalize to the same scope (cleanUsername is many-to-one), which would
	// silently hand the new user another user's home directory. Reject the signup
	// if the derived scope is already taken. When CreateUserDir is off, all
	// signups intentionally share the configured default scope, so this check
	// does not apply.
	if d.settings.CreateUserDir {
		switch _, err := d.store.Users.GetByScope(user.Scope); {
		case err == nil:
			return http.StatusConflict, fberrors.ErrExist
		case !errors.Is(err, fberrors.ErrNotExist):
			return http.StatusInternalServerError, err
		}
	}

	log.Printf("new user: %s, home dir: [%s].", user.Username, userHome)

	err = d.store.Users.Save(user)

The patch introduces a GetByScope lookup that returns HTTP 409 Conflict when the derived scope is already assigned, blocking the collision at registration time.

Detection Methods for CVE-2026-62685

Indicators of Compromise

  • Multiple File Browser accounts whose usernames differ only in separators, spacing, or special characters (for example alice-smith, alice smith, alice/smith).
  • Log entries from log.Printf("new user: %s, home dir: [%s].", ...) where two distinct usernames map to the same home directory path.
  • Unexpected file modifications, uploads, or deletions in a user's scope originating from a session bound to a different account.

Detection Strategies

  • Query the File Browser user store and identify records whose Scope field values collide across different Username values.
  • Review web access logs for POST /api/signup requests followed by successful authentication from IP addresses not previously associated with the account.
  • Correlate signup events against existing user directory listings to flag any new account that resolves to a pre-existing path.

Monitoring Recommendations

  • Alert on any new account creation on File Browser instances where Signup is enabled in the configuration.
  • Track file access patterns per user and flag reads or writes to files created before the accessing account existed.
  • Monitor the File Browser BoltDB user store for scope duplication using scheduled integrity checks.

How to Mitigate CVE-2026-62685

Immediate Actions Required

  • Upgrade File Browser to version 2.63.17 or later, which rejects signups whose normalized scope collides with an existing user.
  • If upgrade is not immediately possible, set Signup=false in the File Browser configuration to disable public account registration.
  • Audit the existing user database for scope collisions and remove or reassign any duplicate-scope accounts before restoring signup.

Patch Information

The fix is available in File Browser release v2.63.17. The patch is implemented in commit 883a36f and adds a GetByScope uniqueness check in the signup handler in http/auth.go. Full advisory details are published as GHSA-7rc3-g7h6-22m7.

Workarounds

  • Disable CreateUserDir so all signups share the configured default scope, eliminating the derivation collision path.
  • Restrict signup to an internal network or place File Browser behind an authenticating reverse proxy until patching is complete.
  • Manually provision accounts with administrator-chosen usernames rather than allowing self-service signup.
bash
# Verify installed File Browser version and upgrade
filebrowser version

# Docker-based upgrade to the patched release
docker pull filebrowser/filebrowser:v2.63.17
docker stop filebrowser && docker rm filebrowser
docker run -d --name filebrowser \
  -v /srv/filebrowser/data:/srv \
  -v /srv/filebrowser/database.db:/database.db \
  -v /srv/filebrowser/settings.json:/.filebrowser.json \
  filebrowser/filebrowser:v2.63.17

# Temporary mitigation: disable public signup
filebrowser config set --signup=false

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.