The /api/fs/batch_rename handler in OpenList v4 validates and authorizes only the source directory (src_dir) but does not validate the source filename (src_name) for path traversal. While new_name is checked to reject path separators, src_name can include traversal segments such as '../../ab/secret.txt'. The handler concatenates src_dir and src_name, then normalizes the path, which can escape the authorized directory. This allows an authenticated user with rename permission to rename files outside their base path, violating access controls. The vulnerability is due to missing validation on src_name in batch rename operations, unlike single-file rename which properly validates the filename. The issue affects versions before 4.2.4 and has been confirmed with a proof-of-concept test.

An authenticated user with rename permissions can rename files outside their authorized directory by exploiting path traversal in the source filename parameter. This can lead to unauthorized modification or relocation of files outside the user's base path, potentially impacting data integrity and confidentiality. The vulnerability does not require administrative privileges but does require authentication and rename permission. The CVSS score of 7.6 reflects a high severity with low attack complexity, requiring privileges, no user interaction, and impacts confidentiality, integrity, and availability to a limited extent.

A patch is available for OpenList v4 that fixes this vulnerability by properly validating the source filename parameter in batch rename operations to prevent path traversal. Users should upgrade to version 4.2.4 or later. Until patched, restrict rename permissions to trusted users only. No other specific mitigations are indicated by the vendor advisory.