GHSA-86cx-wwf4-phq4

### Summary An authorization bypass vulnerability exists in the file sharing mechanism of `Openlist`. Due to a flawed, non-separator-aware path validation check, an authenticated user can create share links for files outside their restricted base directory. This allows an attacker to bypass tenant/user isolation and gain unauthorized read access to arbitrary files within the system. ### Details When a user attempts to create or update a file share, the application must verify that the requested file path falls within the user's assigned `BasePath`. However, in `server/handles/sharing.go`, this authorization check relies on a simple string prefix function: `strings.HasPrefix(requested_path, user.BasePath)`. Because `strings.HasPrefix` does not account for directory separators (e.g., `/`), an attacker whose `BasePath` is assigned to `/base` can supply a target path like `/base2/secret_document.txt`. The validation `strings.HasPrefix("/base2/secret_document.txt", "/base")` evaluates to `true`, successfully passing the authorization filter. Once the share is created, the public share download/list handlers unwrap and serve the file based on the stored absolute path without re-verifying the creator's current directory scope, granting the attacker horizontal access to unauthorized data. ### PoC **Prerequisites:** 1. A system with at least two distinct directories at the root level: `/base` and `/base2`. 2. A sensitive file exists at `/base2/secret.txt`. 3. An attacker account with the `CanShare` permission enabled and its `Base path` strictly limited to `/base`. **Exploitation Steps:** 1. Log in as the attacker account and obtain the JWT authorization token. 2. Send a `POST` request to create a new share, intentionally targeting the unauthorized sibling directory `/base2`: ```http POST /api/share/create HTTP/1.1 Host: <your-openlist-host> Authorization: <attacker-jwt-token> Content-Type: application/json { "files": ["/base2/secret.txt"], "pwd": "", "max_acce