high · 7.6Jul 24, 2026

OpenList Authenticated Path Traversal in Batch Rename src_name

Rohit Hatagale
AI Security Researcher, SecureLayer7

A logged-in OpenList user can rename files outside their assigned base directory by injecting dot-dot path segments into the batch rename API, letting them corrupt or displace other users' files.

Packagegithub.com/OpenListTeam/OpenList/v4
Ecosystemgo
Affected<= 4.2.3
Fixed in4.2.4
OpenList Authenticated Path Traversal in Batch Rename src_name

The problem

The POST /api/fs/batch_rename handler authorizes writes against the caller's resolved src_dir, then builds the source path by concatenating that directory with the attacker-supplied src_name field without any validation.

Because src_name is never passed through the checkRelativePath guard that protects new_name and the single-file rename path, Go's path.Clean silently resolves traversal segments after the fact. A user confined to /team/a can therefore rename /team/ab/secret.txt by submitting src_name: "../../ab/secret.txt" while src_dir points to their permitted /writable subdirectory.

Proof of concept

A working proof-of-concept for this issue in github.com/OpenListTeam/OpenList/v4, with the exact payload below.

http
POST /api/fs/batch_rename HTTP/1.1
Host: openlist.example.com
Content-Type: application/json
Authorization: Bearer <user_token>

{
  "src_dir": "/writable",
  "rename_objects": [
    {
      "src_name": "../../ab/secret.txt",
      "new_name": "renamed.txt"
    }
  ]
}

The handler calls user.JoinPath(req.SrcDir) to constrain the base directory, and it calls checkRelativePath only on renameObject.NewName. The source path is built as fmt.Sprintf("%s/%s", reqPath, renameObject.SrcName) and passed directly to fs.Rename. The lower-level FixAndCleanPath runs path.Clean on the result, which resolves ../../ab/secret.txt into a fully normalized path that escapes the authorized directory entirely.

The patch at commit 651da18 adds a checkRelativePath(renameObject.SrcName) call before that Sprintf, mirroring the guard already present on the destination name and on the single-file rename path in fsmanage.go. CWE-22 applies: the restriction of the pathname to a safe base was incomplete because one attacker-controlled path component was never validated.

The fix

Upgrade to OpenList v4.2.4. The fix (commit 651da18da4c647d96648d4bb64462baac1c37e04) validates src_name with checkRelativePath before constructing the source file path in the batch rename handler, rejecting any value that contains path separators, empty strings, dots, or double-dot sequences.

Reported by Thai Son Dinh, VinSOC Labs (R&D).

References: [1][2][3][4]

Related research