<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 23:45:20 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-69160</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-69160</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-69160</guid>
    </item>
    <item>
      <title>GHSA-86cx-wwf4-phq4 — OpenList: Arbitrary File Read via Path Prefix Confusion in Share Creation API</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-86cx-wwf4-phq4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/OpenListTeam/OpenList/v4&lt;/p&gt;
&lt;p&gt;### Summary
An authorization bypass vulnerability exists in the file sharing mechanism of `Openlist`. Due to a flawed, non-separator-aware path validation check, an authenticated user can create share links for files outside their restricted base directory. This allows an attacker to bypass tenant/user isolation and gain unauthorized read access to arbitrary files within the system.&lt;/p&gt;
&lt;p&gt;### Details
When a user attempts to create or update a file share, the application must verify that the requested file path falls within the user&amp;#39;s assigned `BasePath`. However, in `server/handles/sharing.go`, this authorization check relies on a simple string prefix function: `strings.HasPrefix(requested_path, user.BasePath)`.&lt;/p&gt;
&lt;p&gt;Because `strings.HasPrefix` does not account for directory separators (e.g., `/`), an attacker whose `BasePath` is assigned to `/base` can supply a target path like `/base2/secret_document.txt`. The validation `strings.HasPrefix(&amp;#34;/base2/secret_document.txt&amp;#34;, &amp;#34;/base&amp;#34;)` evaluates to `true`, successfully passing the authorization filter.&lt;/p&gt;
&lt;p&gt;Once the share is created, the public share download/list handlers unwrap and serve the file based on the stored absolute path without re-verifying the creator&amp;#39;s current directory scope, granting the attacker horizontal access to unauthorized data.&lt;/p&gt;
&lt;p&gt;### PoC
**Prerequisites:**
1. A system with at least two distinct directories at the root level: `/base` and `/base2`.
2. A sensitive file exists at `/base2/secret.txt`.
3. An attacker account…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/OpenListTeam/OpenList/v4&lt;/p&gt;
&lt;p&gt;### Summary
An authorization bypass vulnerability exists in the file sharing mechanism of `Openlist`. Due to a flawed, non-separator-aware path validation check, an authenticated user can create share links for files outside their restricted base directory. This allows an attacker to bypass tenant/user isolation and gain unauthorized read access to arbitrary files within the system.&lt;/p&gt;
&lt;p&gt;### Details
When a user attempts to create or update a file share, the application must verify that the requested file path falls within the user&amp;#39;s assigned `BasePath`. However, in `server/handles/sharing.go`, this authorization check relies on a simple string prefix function: `strings.HasPrefix(requested_path, user.BasePath)`.&lt;/p&gt;
&lt;p&gt;Because `strings.HasPrefix` does not account for directory separators (e.g., `/`), an attacker whose `BasePath` is assigned to `/base` can supply a target path like `/base2/secret_document.txt`. The validation `strings.HasPrefix(&amp;#34;/base2/secret_document.txt&amp;#34;, &amp;#34;/base&amp;#34;)` evaluates to `true`, successfully passing the authorization filter.&lt;/p&gt;
&lt;p&gt;Once the share is created, the public share download/list handlers unwrap and serve the file based on the stored absolute path without re-verifying the creator&amp;#39;s current directory scope, granting the attacker horizontal access to unauthorized data.&lt;/p&gt;
&lt;p&gt;### PoC
**Prerequisites:**
1. A system with at least two distinct directories at the root level: `/base` and `/base2`.
2. A sensitive file exists at `/base2/secret.txt`.
3. An attacker account…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-86cx-wwf4-phq4</guid>
    </item>
  </channel>
</rss>
