Vulnerabilities

Vulnerability · CVE-2026-102663

OpenList: Search metadata/count disclosure via Non-Separator-Aware Path Check in Bleve Search

Published Jul 24, 2026 · catalog updated Oct 13, 2026 · OpenList: Search metadata/count disclosure

Check if you run it

No confirmed exploitation is on record for CVE-2026-102663. EPSS is 0.21%. Act only if a listed version of OpenList: Search metadata/count disclosure is installed.

Severity

Medium4.3

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.21%

Remediation

Advisory link

Affected products

Go github.com/OpenListTeam/OpenList · Go github.com/OpenListTeam/OpenList/v3 · Go github.com/OpenListTeam/OpenList/v4

### Summary An authorization bypass and information disclosure vulnerability exists in the search API of . Due to a non-separator-aware path check and unfiltered backend counting, a low-privileged user can bypass their assigned restrictions to discover and access metadata of files residing in unauthorized sibling directories. ### Details This vulnerability stems from two combined logic flaws when the search engine is utilized: 1. **Insecure Path Prefix Validation:** In the search handler ( ), the application attempts to restrict search results to the user's allowed namespace using a simple prefix check: . Because this function is not path-separator aware, a user with a restricted to will successfully pass the authorization check for a completely separate directory named (since "/base2" starts with "/base"). 2. **Unfiltered Total Count Leakage:** The backend ( ) searches the index globally and ignores the boundary. Even if the application later successfully filters out unauthorized items from the array (e.g., via meta password checks), it still returns the raw count provided by the search backend. This allows an attacker to perform blind data-enumeration, confirming the existence of sensitive files outside their namespace by observing the count. ### PoC **Prerequisites:** 1. Log in as an administrator and set the Search Index Mode to . Build the index. 2. Create two directories at the root level: and . 3. Upload a sensitive file into the unauthorized directory: . 4. Create a low-privileged test user and strictly set their to . **Exploitation Steps:** 1. Authenticate as the newly created low-privileged user. 2. Send the following HTTP request to the search API: 3. Observe the response: Due to the prefix bypass ( ), the metadata for will be leaked in the response Content. - Alternatively, even if access is further blocked by folder-level passwords, the Total field will return > 0, allowing the attacker to blindly confirm the existence of the keyword "secret" in unautho