Description

OpenList a file list program that supports multiple storage. Prior to 4.2.4, the share creation and update checks in server/handles/sharing.go use strings.HasPrefix(requested_path, user.BasePath) without enforcing a directory separator boundary. An authenticated user with CanShare permission and a BasePath such as /base can submit a sibling path such as /base2/secret.txt, create a share for the out-of-scope file, and use the public share download or list handlers to read data outside the assigned directory. This issue is fixed in version 4.2.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-18T18:19:28.493Z",
  "pubdate": "2026-08-18T18:19:28.493Z",
  "executiveSummary": "A path traversal vulnerability exists in OpenList prior to version 4.2.4, specifically within the share creation and update validation logic located in server/handles/sharing.go. The vulnerability arises from improper boundary enforcement when validating requested paths against user base paths using strings.HasPrefix(requested_path, user.BasePath).\nAn authenticated attacker possessing the CanShare permission can exploit this flaw to bypass directory restriction boundaries. By supplying a crafted sibling path—such as targeting /base2/secret.txt when assigned a BasePath of /base—an attacker can successfully create unauthorized shares for out-of-scope files and directories.\nThe impact of this vulnerability allows malicious actors to leverage public share download or list handlers to read sensitive data outside their assigned directory scope, resulting in unauthorized information disclosure and a breach of data isolation boundaries.\nExploitation requires authentication, specifically an account with the CanShare privilege, and network access to the OpenList server application. The risk is mitigated by updating the software to version 4.2.4 or later, where proper directory separator boundary checks are enforced.",
  "technicalDetails": "The root cause of the vulnerability resides in the validation mechanism implemented in server/handles/sharing.go for share creation and update operations prior to version 4.2.4. The application evaluates whether a requested path falls within a user's permitted directory tree by utilizing the Go standard library function strings.HasPrefix(requested_path, user.BasePath).\nThis function performs a purely lexical prefix match without verifying whether the boundary coincides with a directory separator. Consequently, a user restricted to a base path such as /base can provide a maliciously crafted input string like /base2/secret.txt. Because the string /base2 begins with the literal characters /base, the validation check incorrectly evaluates to true, bypassing the intended security control.\nThe vulnerable component is the path validation logic inside the sharing handler of OpenList. The affected versions include all releases prior to version 4.2.4. The attack requires the adversary to be authenticated and possess the CanShare permission within the system, operating over the network interface exposed by the OpenList server.\nThe step-by-step attack flow proceeds as follows: First, the authenticated attacker with CanShare privileges identifies their assigned BasePath (e.g., /base). Second, the attacker formulates an API request to create or update a share, supplying a target path that utilizes a sibling directory naming convention (e.g., /base2/secret.txt). Third, the vulnerable server processes the request using strings.HasPrefix, which fails to detect the absence of a trailing directory separator, thereby authorizing the out-of-scope path. Fourth, the server generates a public share link for the unauthorized resource. Finally, the attacker accesses the public share download or list handlers to retrieve the contents of the sensitive file located outside the designated directory structure, achieving unauthorized data exfiltration."
}