<?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 21:49:54 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-87016 — Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite</title>
      <link>https://db.gcve.eu/vuln/cve-2026-87016</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; open-webui&lt;/p&gt;
&lt;p&gt;Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.6.41 until 0.11.1, get_user_by_oauth_sub and get_user_by_scim_external_id in backend/open_webui/models/users.py used JSON contains matching that compiled to SQL LIKE substring matching on SQLite. An OAuth subject containing percent or underscore wildcard characters could resolve to a different stored identity, potentially selecting an administrator account and issuing the attacker that account&amp;#39;s session; PostgreSQL deployments were not affected. This issue is fixed in version 0.11.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; open-webui&lt;/p&gt;
&lt;p&gt;Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.6.41 until 0.11.1, get_user_by_oauth_sub and get_user_by_scim_external_id in backend/open_webui/models/users.py used JSON contains matching that compiled to SQL LIKE substring matching on SQLite. An OAuth subject containing percent or underscore wildcard characters could resolve to a different stored identity, potentially selecting an administrator account and issuing the attacker that account&amp;#39;s session; PostgreSQL deployments were not affected. This issue is fixed in version 0.11.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-87016</guid>
    </item>
    <item>
      <title>PYSEC-2026-4128 — Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite</title>
      <link>https://db.gcve.eu/vuln/pysec-2026-4128</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: open-webui&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;On SQLite deployments, the lookup that maps an external identity to a local account does a substring match instead of an exact match. A subject value containing SQL wildcard characters therefore matches accounts the value was never issued for, and the sign-in binds to whichever account the database returns first, which can be an administrator. The same defect affects SCIM external-ID resolution. PostgreSQL deployments are not affected, because they take a separate and correct code path.&lt;/p&gt;
&lt;p&gt;## Preconditions&lt;/p&gt;
&lt;p&gt;* The database is SQLite. This is the default backend. PostgreSQL deployments are not affected at all.
* OAuth or OIDC sign-in is configured, or SCIM provisioning is enabled. Both are off by default.
* For an attacker to steer the match deliberately, they must control the value of the claim Open WebUI uses as the subject. That value is normally assigned by the identity provider and is not attacker-controlled: the shipped GitHub and Feishu configurations use provider-assigned numeric identifiers, and a standard OIDC `sub` is provider-assigned. The deliberate case therefore requires an operator to have pointed `OAUTH_SUB_CLAIM` at a claim the end user can set at the identity provider, such as a username or email claim, or an identity provider that lets a user choose their own subject value.
* No attacker and no misconfiguration are needed for the accidental case. A legitimate subject value that happens to contain an underscore matches other accounts as well, and w…&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&lt;/p&gt;
&lt;p&gt;On SQLite deployments, the lookup that maps an external identity to a local account does a substring match instead of an exact match. A subject value containing SQL wildcard characters therefore matches accounts the value was never issued for, and the sign-in binds to whichever account the database returns first, which can be an administrator. The same defect affects SCIM external-ID resolution. PostgreSQL deployments are not affected, because they take a separate and correct code path.&lt;/p&gt;
&lt;p&gt;## Preconditions&lt;/p&gt;
&lt;p&gt;* The database is SQLite. This is the default backend. PostgreSQL deployments are not affected at all.
* OAuth or OIDC sign-in is configured, or SCIM provisioning is enabled. Both are off by default.
* For an attacker to steer the match deliberately, they must control the value of the claim Open WebUI uses as the subject. That value is normally assigned by the identity provider and is not attacker-controlled: the shipped GitHub and Feishu configurations use provider-assigned numeric identifiers, and a standard OIDC `sub` is provider-assigned. The deliberate case therefore requires an operator to have pointed `OAUTH_SUB_CLAIM` at a claim the end user can set at the identity provider, such as a username or email claim, or an identity provider that lets a user choose their own subject value.
* No attacker and no misconfiguration are needed for the accidental case. A legitimate subject value that happens to contain an underscore matches other accounts as well, and w…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/pysec-2026-4128</guid>
    </item>
  </channel>
</rss>
