CVE-2026-73509 in OpenList
Summary
by MITRE • 08/13/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability described represents a critical path traversal flaw in OpenList file management software affecting versions prior to 4.2.4. This weakness resides within the authenticated batch rename functionality of the application's API, specifically in the server/handles/fsbatch.go component where the system processes batch renaming operations through the /api/fs/batch_rename endpoint. The flaw stems from incomplete input validation mechanisms that fail to properly sanitize user-supplied file paths during the rename operation process.
The technical implementation of this vulnerability occurs when the system authorizes only the source directory path generated by user.JoinPath(req.SrcDir) but neglects to validate the attacker-controlled renameObject.SrcName parameter which is passed as the src_name field. This parameter undergoes validation through checkRelativePath function, but this validation only applies to NewName and not to SrcName itself. The system then concatenates the validated source directory path with the unvalidated SrcName parameter before passing the combined result to fs.Rename function, creating a scenario where traversal sequences can manipulate path normalization behavior.
This vulnerability maps directly to CWE-22 Path Traversal and aligns with ATT&CK technique T1074 Data Staged, as it enables unauthorized file access and manipulation across user boundaries. The flaw allows malicious users with rename permissions to exploit directory traversal sequences within the src_name parameter to bypass authorization checks and target files outside their designated directories. When the system processes these malicious paths through path normalization, it selects files located in different directories than intended, effectively enabling cross-user file integrity compromise.
The operational impact of this vulnerability encompasses multiple security dimensions including unauthorized data access, file integrity manipulation, and limited availability disruption. An attacker can leverage this weakness to perform unauthorized file operations on other users' files, potentially leading to data loss or modification of sensitive information. The system's response behavior provides additional attack surface through error responses that disclose file existence, creating information leakage opportunities. The vulnerability affects the configured base path settings and allows attackers to target files outside their authorized scope, effectively breaking the intended access control boundaries.
Mitigation strategies for this vulnerability should focus on implementing comprehensive input validation across all user-supplied path parameters in the batch rename functionality. The system must validate all components of file paths including both source and destination names against the authorized directory boundaries using strict path normalization routines that reject any traversal sequences. Security controls should enforce absolute path resolution with proper boundary checking before any file operations are permitted, ensuring that no attacker-controlled input can manipulate the final file path beyond authorized directories. Additionally, implementing principle of least privilege access controls and regular security auditing of API endpoints will help prevent similar vulnerabilities from emerging in future versions.
This vulnerability demonstrates the critical importance of input sanitization in web applications where user-supplied data flows directly into system operations, particularly in file management systems where path traversal attacks can lead to severe confidentiality and integrity breaches. The fix implemented in version 4.2.4 should include comprehensive validation of all path components in the batch rename functionality, proper boundary enforcement for directory operations, and robust error handling that does not disclose sensitive file information through response content.