GHSA-95cv-r8x4-vh75: Path Traversal Vulnerability in OpenList Batch Rename Handler

The Go-based backend package github.com/OpenListTeam/OpenList/v4 exposes a file management endpoint /api/fs/batch_rename that allows users to perform multiple rename operations concurrently. Under multi-tenant configurations, users are restricted to a specific home or base directory to prevent cross-tenant data access. However, a validation failure in this batch rename handler allows users to escape their designated directory boundary.\n\nThis vulnerability is classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory, also known as Path Traversal). The attack surface is exposed to any authenticated user who possesses standard file rename permissions. Because the application fails to sanitize one of the main user-provided parameters, an attacker can manipulate files in sibling paths.\n\nWhile single-file rename operations enforce validation checks on both the source and target path parameters, the batch rename handler only validates the target parameter. This omission permits directory traversal sequences inside the source path parameter to resolve to parent directories. The resulting impact is an integrity and availability violation across the local filesystem.

The core vulnerability exists in the handler function FsBatchRename located inside the file server/handles/fsbatch.go. When processing a batch rename request, the HTTP server validates and authorizes the base source directory (req.SrcDir) using the user.JoinPath method. This authorization step ensures that the starting directory path remains within the user's allocated base path, returning a validated base path known as reqPath.\n\nAlthough reqPath is verified, the batch rename mechanism processes individual objects containing a source filename (SrcName) and a target filename (NewName). Inside the processing loop, the application validates the destination filename by calling the helper function checkRelativePath(renameObject.NewName). This function checks for path separators and traversal tokens like .. to prevent the destination from escaping the target folder.\n\nHowever, the handler fails to call checkRelativePath on the source file parameter renameObject.SrcName. Instead, the application directly concatenates reqPath and renameObject.SrcName using string formatting (fmt.Sprintf("%s/%s", reqPath, renameObject.SrcName)). This concatenated string is then passed down to the underlying filesystem interface fs.Rename without further verification.\n\nThe target filesystem layer resolves the combined path using standard library functions such as path.Clean. This cleanup step resolves any directory traversal sequences, such as ../, collapsing them into a normalized path that points outside the authorized reqPath directory tree. Consequently, the backend executes the filesystem rename operation on paths for which the user lacks authorization.

An inspection of the source code confirms the asymmetric validation logic between the source and destination variables. The vulnerable code pathway is implemented within server/handles/fsbatch.go under the batch rename loop. The code block demonstrates that while renameObject.NewName is guarded by checkRelativePath, the renameObject.SrcName variable flows unchecked directly into the path construction logic.\n\ngo\n// Vulnerable Code Path\nfor _, renameObject := range req.RenameObjects {\n if renameObject.SrcName == "" || renameObject.NewName == "" {\n continue\n }\n // Only NewName is validated against relative path patterns\n err = checkRelativePath(renameObject.NewName)\n if err != nil {\n common.ErrorResp(c, err, 403)\n return\n }\n \n // Unvalidated SrcName is concatenated to the authorized reqPath\n filePath := fmt.Sprintf(\"%s/%s\", reqPath, renameObject.SrcName)\n \n // Path cleanup resolves relative traversal tokens, escaping boundaries\n err = fs.Rename(filePath, renameObject.NewName)\n}\n\n\nThe remediation introduced in commit 651da18da4c647d96648d4bb64462baac1c37e04 addresses this gap. The patch inserts a validation step for renameObject.SrcName using the same checkRelativePath function before the path is constructed. If either of the parameters contains path separators or traversal characters, the operation is blocked.\n\ngo\n// Patched Code Path in server/handles/fsbatch.go\nfor _, renameObject := range req.RenameObjects {\n if renameObject.SrcName == "" || renameObject.NewName == "" {\n continue\n }\n // Fix: Validate SrcName using checkRelativePath to block traversal sequences\n err = checkRelativePath(renameObject.SrcName)\n if err != nil {\n common.ErrorResp(c, err, 403)\n return\n }\n err = checkRelativePath(renameObject.NewName)\n if err != nil {\n common.ErrorResp(c, err, 403)\n return\n }\n \n filePath := fmt.Sprintf(\"%s/%s\", reqPath, renameObject.SrcName)\n err = fs.Rename(filePath, renameObject.NewName)\n}\n\n\nThis fix is highly effective because checkRelativePath acts as a strict whitelist, checking for any system path separators. Any attempt to use . or .. or slashes in SrcName returns an error. This prevents the path concatenation function from ever receiving directory traversal tokens, ensuring complete boundary isolation.

Exploitation of this vulnerability requires an authenticated session with standard user privileges and file rename permissions. The attacker must target the /api/fs/batch_rename endpoint by transmitting a crafted JSON payload. The payload must specify a valid source directory that the user has permission to write to, combined with a traversal sequence inside the src_name parameter of the rename_objects array.\n\nBecause the backend relies on path.Clean on the filesystem driver level, the traversal tokens allow the attacker to reference sibling folders. For example, if the user's home path is /team/a and they target a writable directory inside it, they can construct a relative path to reference files located in /team/ab or /team/b. The following request illustrates a typical exploit payload:\n\njson\n{\n "src_dir": "/writable",\n "rename_objects": [\n {\n "src_name": "../../ab/secret.txt",\n "new_name": "renamed.txt"\n }\n ]\n}\n\n\nmermaid\ngraph LR\n A["Attacker Alice Auth Session"] -->|POST /api/fs/batch_rename| B["OpenList API Handler"]\n B -->|Resolve SrcDir: /team/a/writable| C["Valid Path: /team/a/writable"]\n B -->|Concatenate SrcName: ../../ab/secret.txt| D["/team/a/writable/../../ab/secret.txt"]\n D -->|path.Clean Normalization| E["Target: /team/ab/secret.txt"]\n E -->|Rename Command| F["Filesystem Execution Unauthorized Path"]\n\n\nWhen the server processes this request, it first validates that Alice has permission to modify /team/a/writable. It then appends the traversal payload, yielding /team/a/writable/../../ab/secret.txt. The filesystem driver resolves this path to /team/ab/secret.txt. It renames the file to renamed.txt inside the target directory, completing the unauthorized modification.

The vulnerability has significant implications for multi-tenant and multi-user configurations. An attacker restricted to their own folder can rename files belonging to other users or the core system application. This capability directly violates data integrity, as critical files can be renamed, moved, or misplaced without the target user's consent.\n\nFurthermore, availability is severely impacted. By renaming crucial configuration files, system scripts, or database files to random names, an attacker can disable services, leading to a localized denial of service (DoS). If the system attempts to read a file that has been renamed, it will fail, disrupting dependent application flows.\n\nAdditionally, this bug introduces a low-severity confidentiality leak. An attacker can use the API's success and error responses to perform file and directory discovery. By sending speculative rename commands containing traversal paths, the attacker can determine if specific files or directories exist on the server based on whether the endpoint returns a 200 OK or a 404 Not Found error.

To eliminate the vulnerability, administrators must update the Go module github.com/OpenListTeam/OpenList/v4 to version v4.2.4 or later. This version contains the patch that applies the checkRelativePath validation to both input fields. Recompiling the backend with the patched module prevents all path traversal attempts via the batch rename endpoint.\n\nFor systems where an immediate software update is not possible, temporary mitigation can be implemented using a Web Application Firewall (WAF) or a reverse proxy. Administrators can configure a WAF rule to analyze incoming HTTP POST requests directed at /api/fs/batch_rename. The rule should inspect the body for traversal sequences within the JSON payload.\n\nnginx\n# Example Nginx snippet to reject potential traversal payloads\nlocation /api/fs/batch_rename {\n client_max_body_size 10k;\n if ($request_body ~* "src_name.*\\.\\./") {\n return 403;\n }\n proxy_pass http://backend_upstream;\n}\n\n\nIn addition to input validation, organizations should implement the principle of least privilege. Run the application process using a low-privilege system user account. Ensure that filesystem permissions restrict the application process from writing to directories outside of the designated data storage roots, limiting the blast radius of any successful path traversal exploit.