OpenList/V4 <= 4.2.3 - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/openlist/v4--4.2.3/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 24 Jul 2026 22:34:55 +0000OpenList Path Traversal Vulnerability Allows Renaming Files Outside Authorized Pathshttps://feed.craftedsignal.io/briefs/2026-07-openlist-path-traversal/Fri, 24 Jul 2026 22:34:55 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-07-openlist-path-traversal/An authenticated user with rename permissions in OpenList/v4 is vulnerable to a path traversal flaw (GHSA-95cv-r8x4-vh75) in the `/api/fs/batch_rename` handler, allowing them to rename files outside their authorized base path and source directory by injecting traversal segments in the `src_name` parameter, leading to integrity violations and limited availability impact.A high-severity path traversal vulnerability (GHSA-95cv-r8x4-vh75) has been identified in OpenList/v4, specifically affecting versions up to and including 4.2.3. The flaw resides within the /api/fs/batch_rename handler, which is responsible for batch file renaming operations. The vulnerability stems from insufficient validation of the src_name parameter in the HTTP POST request body. While the new_name parameter is properly checked for path separators, src_name is not, allowing an authenticated user with rename permissions to supply directory traversal segments (e.g., ../../) within src_name. This enables the attacker to manipulate the final source path to rename files located outside their designated base path and authorized src_dir, bypassing intended access controls and affecting other users' data.

Attack Chain

  1. An authenticated user with file rename permissions crafts an HTTP POST request targeting the /api/fs/batch_rename endpoint.
  2. The request's JSON body specifies a src_dir (e.g., /writable) that is within the user's legitimately authorized base path (e.g., /team/a).
  3. Within the rename_objects array in the JSON payload, the user sets the src_name parameter to include directory traversal segments (e.g., ../../ab/secret.txt).
  4. The FsBatchRename handler processes the request but fails to adequately validate the src_name parameter for path traversal sequences.
  5. OpenList concatenates the provided src_dir and the attacker-controlled src_name to construct a full source path (e.g., /team/a/writable/../../ab/secret.txt).
  6. Lower-level filesystem path normalization functions resolve these traversal segments, resulting in a final, absolute source path (e.g., /team/ab/secret.txt) that unexpectedly escapes the user's authorized directory.
  7. The application proceeds to rename the file located at this normalized, out-of-scope path (/team/ab/secret.txt) to the specified new_name (e.g., renamed.txt), thereby performing an unauthorized file modification.

Impact

This vulnerability allows an authenticated user to violate the integrity of other users' files by renaming them outside their authorized scope. In a multi-user OpenList deployment, a user confined to a specific base path (e.g., /team/a) can rename sibling files (e.g., /team/ab/secret.txt) belonging to other users. This can lead to limited availability, as crucial files may be moved from their expected locations, disrupting operations. Furthermore, by observing success or error responses from such rename attempts, an attacker could potentially confirm the existence of guessed files outside their base path, aiding in reconnaissance.

Recommendation

Prioritize applying the security patch for OpenList/v4 to address GHSA-95cv-r8x4-vh75 immediately. Implement robust validation for the renameObject.SrcName parameter within the /api/fs/batch_rename handler by applying the same checkRelativePath constraints currently used for renameObject.NewName. Alternatively, ensure that source objects are derived exclusively from a trusted directory listing of reqPath.

]]>highadvisorypath-traversalauthenticated-bypassintegrity-violationweb-application