7.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-54091

CVE-2026-54091: File Browser: Incorrect access control in public directory shares via rule path rebasing

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.6, File Browser's public share handlers rebase the share owner's filesystem root to the shared directory and then evaluate descendant paths against the owner's global and per-user rules using the rebased relative path instead of the original path relative to the owner's scope. As a result, an attacker who knows a public directory share URL can access files and subdirectories that the owner explicitly blocked with rules, as long as those blocked paths are located underneath the shared directory. In the simplest case this is an unauthenticated information disclosure through GET /api/public/share/* and GET /api/public/dl/*. This vulnerability is fixed in 2.63.6.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-54091

CVE-2026-54091:

7.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

SSVC / BOD 26-04 ↗

Exploitation NoneAutomatable YesTech Impact Partial

Select your environment

→SSVCDeferfix on upgrade

Runtime reachability resolves your actual outcome.Book a demo

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/filebrowser/filebrowser/v2	go	<= 2.63.5	2.63.6
github.com/filebrowser/filebrowser	go	<= 1.11.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability exists in the public sharing feature of File Browser. When a directory is shared, the application creates a new virtual filesystem rooted at that directory to restrict access. However, the access control rule checking mechanism was not made aware of this change of root. The data.Check function, which is responsible for rule validation, would receive a path relative to the new root (e.g., /secret.txt) and compare it against rules defined from the user's actual filesystem root (e.g., /projects/private/secret.txt). The mismatch in paths caused deny rules to be bypassed, allowing unauthorized access.

The patch addresses this by introducing a checkerPrefix field in the data struct. This field stores the base path of the shared directory. The withHashFile middleware, which performs the filesystem rebasing, was modified to set this prefix. Subsequently, the data.Check function was updated to prepend this prefix to the incoming path, effectively reconstructing the original, absolute path before performing the rule check. This ensures that rules are correctly applied even when dealing with rebased public shares.

The identified vulnerable functions are the HTTP handlers (publicShareHandler, publicDlHandler) that serve as the entry points for the exploit, the middleware (withHashFile) that contains the core flawed logic, and the rule checking function (data.Check) that performs the incorrect validation.

Vulnerable functions

fbhttp.data.Check

http/data.go

This function is responsible for checking if a requested path is allowed by the configured rules. In the vulnerable version, it receives a path relative to the shared directory for public shares. It then compares this relative path against rules that are defined with respect to the user's original filesystem root. This mismatch causes the rule check to fail to find a match for deny rules, thus improperly granting access to restricted files and directories.

fbhttp.withHashFile

http/public.go

This middleware function is central to the vulnerability. It rebases the filesystem to the shared directory's path. In the vulnerable version, after rebasing, it fails to preserve the original path context for subsequent access control checks. This leads to the `data.Check` function receiving a relative path, causing an authorization bypass. The fix was to store the base path in `d.checkerPrefix` so that `data.Check` can reconstruct the full path.

fbhttp.publicShareHandler

http/public.go

This function handles API requests to list the contents of a public share. It is an entry point for the vulnerability. It relies on the `withHashFile` middleware, which incorrectly sets up the filesystem context for access control checks, leading to an authorization bypass when listing directory contents that should be restricted by rules.

fbhttp.publicDlHandler

http/public.go

This function handles API requests to download files from a public share. It is another entry point for the vulnerability. It uses the `withHashFile` middleware, which leads to the `data.Check` function being called with a relative path, allowing an attacker to download files that are explicitly denied by the user's rules.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.