<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-15T15:10:20.782804+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-102663</id>
    <title>fkie_cve-2026-102663</title>
    <updated>2026-10-15T15:10:20.784849+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>OpenList is a file list program that supports multiple storage backends. Prior to 4.2.4, the OpenList search API uses a non-separator-aware strings.HasPrefix comparison as a path containment authorization check when authorizing globally indexed Bleve results against a restricted user's BasePath. When Bleve search is enabled and a restricted authenticated user searches the global index for content in a sibling path, the user causes a globally indexed sibling-path result to pass the prefix check. The strings.HasPrefix(node.Parent, user.BasePath) predicate allows a sibling path such as /base2 to be treated as contained by /base. Unauthorized file metadata or file-existence information can be disclosed, and the backend Total value can reveal a match even when another access check removes the individual result. This issue is fixed in version 4.2.4.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-102663"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-p6ph-3jx2-3337</id>
    <title>GHSA-p6ph-3jx2-3337 — OpenList: Search metadata/count disclosure via Non-Separator-Aware Path Check in Bleve Search</title>
    <updated>2026-10-15T15:10:20.784979+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/OpenListTeam/OpenList/v4</p>
<p>### Summary
An authorization bypass and information disclosure vulnerability exists in the search API of `Openlist`. Due to a non-separator-aware path check and unfiltered backend counting, a low-privileged user can bypass their assigned `BasePath` restrictions to discover and access metadata of files residing in unauthorized sibling directories.</p>
<p>### Details
This vulnerability stems from two combined logic flaws when the `bleve` search engine is utilized:</p>
<p>1. **Insecure Path Prefix Validation:** In the search handler (`server/handles/search.go`), the application attempts to restrict search results to the user's allowed namespace using a simple prefix check: `strings.HasPrefix(node.Parent, user.BasePath)`. Because this function is not path-separator aware, a user with a `BasePath` restricted to `/base` will successfully pass the authorization check for a completely separate directory named `/base2` (since "/base2" starts with "/base").</p>
<p>2. **Unfiltered Total Count Leakage:** The `bleve` backend (`internal/search/bleve/search.go`) searches the index globally and ignores the `req.Parent` boundary. Even if the application later successfully filters out unauthorized items from the `Content` array (e.g., via `CanAccess` meta password checks), it still returns the raw `Total` 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 `Total` count.</p>
<p>### PoC
**…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-p6ph-3jx2-3337"/>
  </entry>
</feed>
