GHSA-4mh3-h929-w968

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

### 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: 1. 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. 2. 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. 3. 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](https://github.com/user-attachments/files/24823114/poc.py) The following steps demonstrate the vulnerability: 1. 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" /> 2. 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" /> 3. 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.