Description

OpenList a file list program that supports multiple storage. Prior to 4.2.4, the authenticated /api/fs/batch_rename handler in server/handles/fsbatch.go authorizes only the source directory produced by user.JoinPath(req.SrcDir) and validates renameObject.NewName with checkRelativePath, but does not validate attacker-controlled renameObject.SrcName, supplied as src_name, before concatenating it with the authorized path and passing the result to fs.Rename. A user with rename permission can use traversal segments in src_name to make path normalization select a file outside the authorized directory and configured base path, resulting in cross-user file integrity loss, limited availability impact, and file-existence disclosure through success or error responses. This issue is fixed in version 4.2.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-08-13T15:20:17.623Z",
  "pubdate": "2026-08-13T15:20:17.623Z",
  "executiveSummary": "A path traversal vulnerability exists in the OpenList file list program prior to version 4.2.4. The vulnerability resides within the authenticated /api/fs/batch_rename handler located in server/handles/fsbatch.go. The root cause is the failure to validate the attacker-controlled renameObject.SrcName parameter, supplied as src_name, prior to concatenating it with the authorized base path and passing the resultant path to the fs.Rename function.\nAn authenticated user possessing rename permissions can exploit this flaw by supplying path traversal segments within the src_name parameter. This manipulation bypasses directory restrictions enforced by user.JoinPath(req.SrcDir) and checkRelativePath, allowing the path normalization process to select files outside the authorized directory and the configured storage base path.\nSuccessful exploitation results in cross-user file integrity loss, limited availability impact, and file-existence disclosure inferred through success or error responses returned by the application. The issue is fully remediated in OpenList version 4.2.4.",
  "technicalDetails": "The vulnerability affects OpenList prior to version 4.2.4, specifically within the batch rename functionality handled by the server/handles/fsbatch.go source file at the /api/fs/batch_rename endpoint. The vulnerable component fails to properly sanitize user-supplied input before executing file system operations.\nExploitation requires authentication and rename permissions within the application. The network exposure is constrained by the application's listening interface, typically accessible via HTTP/HTTPS APIs.\nThe root cause stems from incomplete input validation during the batch rename process. While the handler correctly authorizes the source directory generated via user.JoinPath(req.SrcDir) and validates renameObject.NewName using the checkRelativePath function, it fails to apply equivalent validation to the attacker-controlled renameObject.SrcName parameter, passed via the src_name field in the request payload.\nThe attack flow proceeds as follows: 1) An authenticated attacker with rename permissions initiates a batch rename request to the /api/fs/batch_rename endpoint. 2) The attacker supplies crafted traversal sequences (such as dot-dot-slash patterns) within the src_name parameter. 3) The application concatenates the unsanitized src_name with the authorized source directory path. 4) Path normalization resolves the combined string, allowing access to files and directories located outside the intended scope and beyond the configured base path. 5) The manipulated path is subsequently passed directly to the fs.Rename function.\nPost-exploitation impacts include cross-user file integrity loss, limited availability disruption due to unintended file renaming or displacement, and file-existence disclosure. The disclosure of file existence is achieved by observing differential success or error responses returned by the server when targeting arbitrary system paths."
}