CVE-2026-35605
Path Traversal in File Browser Access Rules Allows Unauthorized Directory Access
Publication date: 2026-04-07
Last updated on: 2026-04-16
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| filebrowser | filebrowser | to 2.63.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-22 | The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows authenticated users to bypass intended access restrictions by improperly matching directory paths, potentially granting access to unauthorized directories and files.
Such unauthorized access could lead to exposure of sensitive or regulated data, which may violate compliance requirements under standards like GDPR or HIPAA that mandate strict access controls and data protection.
Therefore, this vulnerability could negatively impact compliance by enabling access control failures that compromise data confidentiality and integrity.
Can you explain this vulnerability to me?
This vulnerability in File Browser arises from improper directory boundary enforcement in the path matching logic used to apply access rules. The Matches() function uses a simple prefix check (strings.HasPrefix) to determine if a file path matches an access rule path. However, it does not ensure that the prefix match ends at a directory boundary. For example, a rule intended for the directory "/uploads" would also match paths like "/uploads_backup/", which are sibling directories and should not be matched. This flaw can cause access rules to grant or deny access to unintended directories.
The issue was fixed by modifying the matching logic to append a trailing slash to the rule path (except for root) and checking if the requested path either exactly matches the rule path or starts with the rule path plus a trailing slash. This ensures that only the intended directory or its subdirectories are matched, preventing false positives on similarly named sibling directories.
How can this vulnerability impact me? :
This vulnerability can allow authenticated users to bypass intended access restrictions by gaining access to sibling directories that share a common prefix with an allowed directory. For example, if access is granted to "/uploads", a user might also gain unintended access to "/uploads_backup/" or other similarly named directories.
Such unauthorized access can lead to exposure of sensitive files or data stored in directories that were meant to be restricted, potentially compromising confidentiality and security of the system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves improper directory boundary enforcement in path matching within the File Browser application. Detection involves verifying if access rules incorrectly allow access to sibling directories sharing a common prefix.
To detect this issue, you can test access rules configured in File Browser by attempting to access directories that share prefixes with allowed directories but should be restricted. For example, if a rule allows access to "/uploads", try accessing "/uploads_backup/" or similar sibling directories to see if access is improperly granted.
Since this is a logic flaw in the application code, network-level detection commands are limited. However, you can use curl or similar HTTP clients to test access paths:
- curl -I http://<filebrowser-host>/uploads_backup/
- curl -I http://<filebrowser-host>/uploads/
Compare the HTTP response headers or status codes to determine if access is granted where it should not be.
Additionally, review the File Browser configuration files or rules to identify any rules that use prefixes without trailing slashes, which may be vulnerable.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade File Browser to version 2.63.1 or later, where the vulnerability is fixed by correcting the path matching logic.
If upgrading immediately is not possible, review and adjust access rules to ensure that directory prefixes end with a trailing slash or are exact matches to prevent unintended access to sibling directories.
As a temporary workaround, restrict access to sensitive directories by more specific rules or by limiting authenticated user permissions to reduce the risk of unauthorized access.
Monitor access logs for suspicious requests attempting to access sibling directories of allowed paths.