GHSA-4mh3-h929-w968 CVE-2026-25890 GO-2026-4474

File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL

High Go

Severity: 8.1 / 10; High · CVSS 3.1
Exploit chance (EPSS): 0.51%; Chance of exploitation in the next 30 days. Higher than 43.41% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-706 Use of Incorrectly-Resolved Name or Reference; CWE-863 Incorrect Authorization
Fix: 2.57.1; Upgrade github.com/filebrowser/filebrowser/v2 to this version or later

Description

Summary

An authenticated user can bypass the application's "Disallow" file path rules by modifying the request URL. By adding multiple slashes (e.g., //private/) to the path, the authorization check fails to match the rule, while the underlying filesystem resolves the path correctly, granting unauthorized access to restricted files.

Details

The vulnerability allows users to bypass "Disallow" rules defined by administrators.

The issue stems from how the application handles URL path normalization and rule matching:

Router Configuration: The router in http/http.go is configured with r.SkipClean(true). This prevents the automatic collapse of multiple slashes (e.g., // becoming /) before the request reaches the handler.
Insecure Rule Matching: The rule enforcement logic in rules/rules.go relies on a simple string prefix match: strings.HasPrefix(path, r.Path). If a rule disallows /private, a request for //private fails this check because //private does not strictly start with /private.
Filesystem Resolution: After bypassing the rule check, the non-normalized path is passed to the filesystem. The filesystem treats the multiple slashes as a single separator, successfully resolving //private/secret.txt and serving the file.

PoC

Python minimal PoC

The following steps demonstrate the vulnerability:

Setup:

Admin user creates a folder /private and adds a file /private/secret.txt. <img width="971" height="719" alt="Screenshot_20260123_151608" src="https://github.com/user-attachments/assets/2071c92e-2bbe-46f8-a338-05b0f53d381a" /> <img width="890" height="386" alt="Screenshot_20260123_151551" src="https://github.com/user-attachments/assets/1def540a-de26-4666-a6ab-058d5927bfbe" />
Admin adds a Disallow rule for user bob on the path /private. <img width="1005" height="1126" alt="Screenshot_20260123_151502" src="https://github.com/user-attachments/assets/e9b57d59-f4ab-41d8-b056-8ffdaa219963" />

Verification:

User bob requests GET /api/resources/private/secret.txt.
Server responds: 403 Forbidden. <img width="1193" height="721" alt="Screenshot_20260123_154446" src="https://github.com/user-attachments/assets/dd092a10-2f8c-4a3c-b48f-d540c483bb5a" />

Exploit:

User bob requests GET /api/resources//private/secret.txt.
Server responds: 200 OK (Bypass successful). <img width="1193" height="721" alt="Screenshot_20260123_154544" src="https://github.com/user-attachments/assets/27ebb82c-f7c2-467d-ae82-f495ae3aa2d4" /> <img width="1196" height="818" alt="Screenshot_20260123_154618" src="https://github.com/user-attachments/assets/82035884-9a24-490d-b928-7bdd2dbe3193" />

Impact

This vulnerability impacts the confidentiality and integrity of data stored in filebrowser.

Confidentiality: Users can read files they are explicitly forbidden from accessing.
Integrity: If the user has general write permissions but is restricted from specific directories via rules, they can bypass these restrictions to rename, delete, or modify files.

Affected versions

Go

Package	Vulnerable	Fixed in
github.com/filebrowser/filebrowser	`all versions`	No fix yet
github.com/filebrowser/filebrowser/v2	`< 2.57.1`	`2.57.1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/filebrowser/filebrowser/v2 Go → `2.57.1`

go

go get github.com/filebrowser/filebrowser/v2@v2.57.1 && go mod tidy

Severity breakdown

CVSS 3.1 8.1

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Attack vector: Network
Attack complexity: Low
Privileges required: Low
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: None

Weakness

CWE-706: Use of Incorrectly-Resolved Name or Reference

The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it

Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2026-25890

Packages

github.com/filebrowser/filebrowser

Timeline

Feb 9, 2026 Published
Sep 10, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-833g-cqhp-h72j File Browser: Share API exposes the password hash and bypass token	Low	Also affects github.com/filebrowser/filebrowser
GHSA-83xp-526h-j3ww File Browser: Archive builder turns backslash filenames into path traversal (zip-slip)	Medium	Also affects github.com/filebrowser/filebrowser
GHSA-7rc3-g7h6-22m7 File Browser: Colliding username normalization gives two users the same home directory	High	Also affects github.com/filebrowser/filebrowser
GHSA-8wc8-hf36-mjh9 File Browser: ScopedFs follows a dangling symlink on write, letting a scoped user create files outside their scope	Medium	Also affects github.com/filebrowser/filebrowser
GHSA-fmm7-x4gx-8jhr File Browser: Out-of-scope file deletion by a Create-only scoped user via symlink-following RemoveAll in upload failure-cleanup	High	Also affects github.com/filebrowser/filebrowser
GHSA-xqp3-jq6g-x3qm File Browser: Authentication Bypass via Proxy Auth Header Forgery	Critical	Also affects github.com/filebrowser/filebrowser
GHSA-m93h-4hw7-5qcm File Browser: Command Injection via Authentication Hook Shell Substitution (Pre-Authentication RCE)	Critical	Also affects github.com/filebrowser/filebrowser
GHSA-8c9q-7855-wfxq File Browser has a Command Execution Allowlist Bypass via Shell Metacharacter Injection	High	Also affects github.com/filebrowser/filebrowser

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor