CVE-2026-25890: The Double-Slash Bypass in File Browser

File Browser is one of those tools sysadmins love. It’s a sleek, single-binary solution that turns any directory on your server into a full-fledged file management interface. It’s convenient, fast, and—until recently—had a glaring hole in its authorization logic that made its permission system about as effective as a 'Keep Out' sign written in invisible ink.

The core promise of File Browser includes a feature called 'Global Scope' or user-specific scopes, often paired with a 'Disallow' list. You, the responsible admin, configure the app to serve /srv/data but explicitly ban access to /srv/data/private. You test it. You try to go to /private, and you get a 403 Forbidden. You pat yourself on the back and go to lunch.

But here's the problem: You trusted the application to understand what a file path is. In CVE-2026-25890, we find out that File Browser had a bit of an identity crisis regarding URL paths. By simply asking for the file nicely—or rather, by stuttering your request with an extra slash—you could walk right past the bouncer. It’s a classic case of the application layer and the filesystem layer speaking two different dialects.

To understand this vulnerability, you have to understand URL normalization. When a web server receives a request for //foo/../bar, standard behavior is to 'clean' that path into /bar before doing anything else. This prevents confusion. If you don't clean the path, you rely on string matching against raw input, which is the security equivalent of juggling chainsaws.

File Browser is built on Go and uses the popular Gorilla Mux router. In the affected versions, the router was explicitly configured with SkipClean(true). This flag tells the router: 'Hey, don't touch the path. Give it to me raw.' The developer likely did this to preserve trailing slashes or handle specific redirect behaviors that 'Clean' would mess up.

The authorization middleware checks permissions by looking at the path string. If you disallowed /private, the code effectively asks: Does request.Path start with "/private"?

If I request //private/secret.txt, the router passes //private/secret.txt to the middleware. The middleware compares strings: //private does NOT start with /private. The check passes. The request is allowed.

However, when that path is finally handed off to the Operating System's filesystem calls (like os.Open), the OS looks at //private/secret.txt, shrugs, treats the double slash as a single separator, and serves the file. The app was fooled; the kernel was not.

The smoking gun for this vulnerability is found in http/http.go. It’s rare to see a developer leave a comment that essentially predicts the future regret of a code change, but here we are. The developer explicitly disabled path cleaning to fix a minor annoyance with redirects.

Here is the vulnerable code in the NewHandler function:

// http/http.go (Vulnerable)
r := mux.NewRouter()
// ...
// NOTE: This fixes the issue where it would redirect if people did not put a
// trailing slash in the end. I hate this decision since this allows some awful
// URLs https://www.gorillatoolkit.org/pkg/mux#Router.SkipClean
r = r.SkipClean(true)

> [!NOTE] > The comment "I hate this decision" is the foreshadowing of the century. By prioritizing the user experience of trailing slashes over canonicalization, the application accepted 'awful URLs' that broke the security model.

The fix, applied in commit 489af403, was brutally simple: delete the line. By removing r = r.SkipClean(true), the router reverts to its default secure behavior. Now, //private becomes /private before the security check runs, meaning the prefix match will succeed, and the request will be blocked.

Exploiting this is trivial. It doesn't require memory corruption, complex race conditions, or advanced cryptography. It requires a keyboard and a web browser.

Scenario

An admin has set up File Browser and created a user guest. The admin wants to prevent guest from seeing the server's backup folder, so they add /backups/ to the user's Disallow list.

1. Standard Access (Blocked): The attacker logs in as guest and navigates to https://target.com/api/resources/backups/shadow.zip.

   • Router Path: /backups/shadow.zip
   • Rule Check: StartsWith("/backups/shadow.zip", "/backups/") -> TRUE.
   • Result: 403 Forbidden.

2. The Bypass (Allowed): The attacker modifies the URL manually or uses curl: curl -H "X-Auth: ..." https://target.com/api/resources//backups/shadow.zip

   • Router Path: //backups/shadow.zip (Because of SkipClean(true))
   • Rule Check: StartsWith("//backups/shadow.zip", "/backups/") -> FALSE.
   • Result: 200 OK.

The file acts as if it's in the root scope because the string comparison failed, but the file loader retrieves the content perfectly.

This is a High Severity (8.1) vulnerability for a reason. File Browser is often used to manage sensitive environments—home labs, corporate file shares, or configuration management directories. The 'Disallow' feature is the primary mechanism for segregation of duties.

If you rely on this software to partition access—say, giving a contractor access to /project_a but disallowing /project_a/contracts—this vulnerability renders that segregation null and void. An authenticated user (or an attacker who has compromised a low-level account) can map the entire directory structure and read any file the File Browser process has permission to touch on the OS level.

This is not just an information disclosure; it is a complete subversion of the application's access control model. If the File Browser runs as root (please don't do this) or a privileged user, the attacker can likely read sensitive system files like /etc/shadow or SSH keys if those paths are reachable within the scope.

The remediation path is straightforward: Update immediately.

Official Patch: Upgrade to File Browser v2.57.1 or later. The developers have removed the SkipClean(true) configuration, enforcing strict path normalization for all requests.

Workarounds: If you cannot update the binary immediately, you must assume that your 'Disallow' rules are ineffective against a motivated user. You could attempt to mitigate this at the reverse proxy layer (Nginx/Apache/Caddy) by enforcing path normalization before the request hits File Browser, or by blocking URLs containing double slashes //.

For example, in Nginx, merge_slashes on; is the default, which might save you if Nginx sits in front, as it will collapse // to / before passing it upstream. However, relying on default proxy behavior is risky; patching the application is the only sure fix.