CVE-2026-35605: 
NixOS vulnerability analysis and mitigation

CVE-2026-35605 is an access control bypass vulnerability in File Browser, a web-based file management interface, caused by improper path prefix matching in access rule evaluation. The Matches() function in rules/rules.go uses Go's strings.HasPrefix() without appending a trailing directory separator, allowing a rule configured for /uploads to inadvertently match /uploads_backup/ and similar sibling directories. All versions prior to 2.63.1 (up to and including v2.62.2) are affected. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory, Security Advisory). The vulnerability was reported by researcher kodareef5, published on April 4, 2026, and assigned a CVE on April 7, 2026.

The root cause is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). In rules/rules.go lines 29–35, the non-regex branch of Matches() calls strings.HasPrefix(path, r.Path) without ensuring the match terminates at a directory boundary — meaning a rule path of /shared will match /shared_private/secret.txt because the string /shared is a prefix of /shared_private/secret.txt. The Check() function in http/data.go uses last-match-wins semantics with no secondary validation, so a matching allow rule grants access without further checks. The regex variant of the rule correctly handles boundary matching, but the plain-path variant does not. Exploitation requires knowledge of the directory naming convention used on the target File Browser instance and a valid user account (Security Advisory, Fix PR).

Authenticated users can bypass administrator-configured access rules and gain read or write access to directories that share a name prefix with an explicitly allowed directory, but were intended to be restricted. For example, a user granted access only to /shared could access files in /shared_private/ without authorization. This primarily affects data integrity and confidentiality within the File Browser-managed directory tree, with no direct availability impact. The scope is limited to the directories accessible by the File Browser service account on the host filesystem (Security Advisory).

A proof-of-concept scenario is publicly documented in the GitHub Security Advisory, demonstrating the bypass with specific filesystem paths and step-by-step instructions (Security Advisory). There is no evidence of active in-the-wild exploitation at this time, and the vulnerability has not been added to the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.063% (0.000630), indicating a low near-term exploitation probability. Exploitation requires an authenticated session, which limits the attacker pool but does not eliminate risk in multi-user deployments (GitHub Advisory).

1. Reconnaissance: Identify a File Browser instance running a version prior to 2.63.1. Enumerate the directory structure or infer naming conventions (e.g., /uploads, /shared) from application behavior or documentation.
2. Authenticate: Log in to the File Browser instance with any valid user account that has been granted access to at least one directory (e.g., /shared).
3. Identify sibling directories: Determine whether sibling directories with a common prefix exist on the server (e.g., /shared_private/, /uploads_backup/) that the admin intended to restrict.
4. Craft a path request: Send a file access request (browse, download, or upload) targeting a path in the unintended sibling directory, such as /shared_private/secret.txt.
5. Bypass access rule: Because strings.HasPrefix("/shared_private/secret.txt", "/shared") evaluates to true, the allow rule for /shared matches, and the Check() function grants access to the unintended directory.
6. Access or modify files: Read sensitive files or write/overwrite files in the unintended directory, depending on the permissions configured for the matched rule (Security Advisory).

• Logs: File Browser access logs showing authenticated requests to directories not explicitly granted to a user (e.g., requests to /shared_private/ from a user whose rule only covers /shared); unexpected file access or modification events in audit logs for sibling directories.
• File System: Unexpected file modifications, uploads, or deletions in directories that share a name prefix with explicitly allowed directories (e.g., /uploads_backup/ when only /uploads is in the access rule).
• Network: HTTP requests from authenticated sessions targeting directory paths that differ from the user's configured allowed paths by a suffix (e.g., /shared_private/ vs. /shared/).

Upgrade File Browser to version 2.63.1 or later, which enforces directory boundary checking by appending a trailing / to the rule path before comparison and adding an exact-match check (Security Advisory, Fix PR). If immediate patching is not possible, restrict network access to the File Browser instance using firewall rules or network segmentation to limit exposure to trusted users only. Additionally, audit all existing access rules to identify any prefix-based rules that may unintentionally match sibling directories, and consider switching affected rules to regex-based matching (which correctly handles boundary conditions) as a temporary workaround.