<?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://db.gcve.eu</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>Thu, 01 Oct 2026 15:29:26 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-87997</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-87997</link>
      <description>&lt;p&gt;Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.10.0 until 0.11.1, POST /api/chat/completions and POST /api/v1/chat/completions in backend/open_webui/main.py copied a client-supplied folder_id into a new chat without applying the folder write-access check used by the dedicated chat routes. An authenticated user who knew a shared folder identifier could inject an attacker-controlled chat into a folder where the user had read-only or no write access, causing the entry to appear to authorized folder readers. This issue is fixed in version 0.11.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.10.0 until 0.11.1, POST /api/chat/completions and POST /api/v1/chat/completions in backend/open_webui/main.py copied a client-supplied folder_id into a new chat without applying the folder write-access check used by the dedicated chat routes. An authenticated user who knew a shared folder identifier could inject an attacker-controlled chat into a folder where the user had read-only or no write access, causing the entry to appear to authorized folder readers. This issue is fixed in version 0.11.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-87997</guid>
    </item>
    <item>
      <title>GHSA-3pf7-q2g3-wj28 — Open WebUI: Any authenticated user can inject chats into another user's folder via chat completions</title>
      <link>https://db.gcve.eu/vuln/ghsa-3pf7-q2g3-wj28</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: open-webui&lt;/p&gt;
&lt;p&gt;## Summary
The chat-completions endpoint reads a folder id out of the request body and saves the newly created chat into that folder without checking that the caller is allowed to write there. Any authenticated user who knows a folder&amp;#39;s id can put a chat of their own into another user&amp;#39;s folder, including a shared folder where they hold read-only access and a folder they have no access to at all. The chat then shows up in that folder for everyone who can read it, under a title and with content the attacker controls. The dedicated chat-creation and chat-move endpoints already enforced this check, the chat-completions path did not.&lt;/p&gt;
&lt;p&gt;## Preconditions
- An authenticated account of any role. No elevated permission, no admin involvement.
- Folders enabled, which is the default (`ENABLE_FOLDERS=true`, `USER_PERMISSIONS_FEATURES_FOLDERS=true`).
- The attacker needs the target folder&amp;#39;s id. A member of a shared folder gets it from the shared-folder listing. Sharing a folder with named users is available to ordinary users by default; only wildcard public sharing is gated. A folder that was never shared has an id the attacker cannot obtain through any endpoint available to them, so those folders are not practically reachable.
- Releases before 0.10.0 contain the same missing check but have no read path that lists a folder&amp;#39;s chats across owners, so the injected row was never visible to anyone.&lt;/p&gt;
&lt;p&gt;## Impact
The integrity of folder contents. An attacker who cannot write to a folder can place…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: open-webui&lt;/p&gt;
&lt;p&gt;## Summary
The chat-completions endpoint reads a folder id out of the request body and saves the newly created chat into that folder without checking that the caller is allowed to write there. Any authenticated user who knows a folder&amp;#39;s id can put a chat of their own into another user&amp;#39;s folder, including a shared folder where they hold read-only access and a folder they have no access to at all. The chat then shows up in that folder for everyone who can read it, under a title and with content the attacker controls. The dedicated chat-creation and chat-move endpoints already enforced this check, the chat-completions path did not.&lt;/p&gt;
&lt;p&gt;## Preconditions
- An authenticated account of any role. No elevated permission, no admin involvement.
- Folders enabled, which is the default (`ENABLE_FOLDERS=true`, `USER_PERMISSIONS_FEATURES_FOLDERS=true`).
- The attacker needs the target folder&amp;#39;s id. A member of a shared folder gets it from the shared-folder listing. Sharing a folder with named users is available to ordinary users by default; only wildcard public sharing is gated. A folder that was never shared has an id the attacker cannot obtain through any endpoint available to them, so those folders are not practically reachable.
- Releases before 0.10.0 contain the same missing check but have no read path that lists a folder&amp;#39;s chats across owners, so the injected row was never visible to anyone.&lt;/p&gt;
&lt;p&gt;## Impact
The integrity of folder contents. An attacker who cannot write to a folder can place…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-3pf7-q2g3-wj28</guid>
    </item>
  </channel>
</rss>
