<?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://cve.radiocsirt.org</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>Sat, 10 Oct 2026 05:53:44 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-348796</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-348796</link>
      <description>EUVD-2026-348796</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-348796</guid>
    </item>
    <item>
      <title>fkie_cve-2026-70482</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-70482</link>
      <description>&lt;p&gt;Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.8.0 until 0.11.0, when ENABLE_OAUTH_TOKEN_EXCHANGE=True, /oauth/{provider}/token/exchange accepts a raw provider access token and validates it by calling the provider userinfo endpoint without confirming which OAuth client the token was issued to. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token user, including applications the operator does not control and has never authorized. This issue is fixed in 0.11.0.&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.8.0 until 0.11.0, when ENABLE_OAUTH_TOKEN_EXCHANGE=True, /oauth/{provider}/token/exchange accepts a raw provider access token and validates it by calling the provider userinfo endpoint without confirming which OAuth client the token was issued to. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token user, including applications the operator does not control and has never authorized. This issue is fixed in 0.11.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-70482</guid>
    </item>
    <item>
      <title>GHSA-rq84-p6rr-vf89 — Open WebUI: Account takeover via OAuth token exchange accepting tokens issued to any client</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rq84-p6rr-vf89</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;The OAuth token exchange endpoint accepts a raw provider access token and validates it by calling the provider&amp;#39;s userinfo endpoint. A userinfo endpoint reports only that a token is valid, never which OAuth client it was issued to, and the endpoint performed no audience or client check of its own. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token&amp;#39;s user, including applications the operator does not control and has never authorised.&lt;/p&gt;
&lt;p&gt;## Preconditions&lt;/p&gt;
&lt;p&gt;- `ENABLE_OAUTH_TOKEN_EXCHANGE=True`. Disabled by default, so a stock deployment is not affected.
- The victim already has an Open WebUI account. The endpoint does not create users.
- The attacker can obtain a provider access token for the victim, typically by having them sign in to an unrelated OAuth application on the same provider. On public providers, registering that application is self-service.
- The subject identifier the attacker&amp;#39;s client observes matches the one stored on the victim&amp;#39;s account. Google, GitHub, Okta and self-hosted OIDC servers in default configuration issue a subject that is stable across all clients and are directly affected. Microsoft Entra ID issues per-application subjects, so the match fails there unless `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled or `OAUTH_SUB_CLAIM` points at a globally stable claim such as `oid`.
- `OAUTH_ALLOWED_DOMAINS` is enforced on this endpoint but does not constrain the…&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;The OAuth token exchange endpoint accepts a raw provider access token and validates it by calling the provider&amp;#39;s userinfo endpoint. A userinfo endpoint reports only that a token is valid, never which OAuth client it was issued to, and the endpoint performed no audience or client check of its own. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token&amp;#39;s user, including applications the operator does not control and has never authorised.&lt;/p&gt;
&lt;p&gt;## Preconditions&lt;/p&gt;
&lt;p&gt;- `ENABLE_OAUTH_TOKEN_EXCHANGE=True`. Disabled by default, so a stock deployment is not affected.
- The victim already has an Open WebUI account. The endpoint does not create users.
- The attacker can obtain a provider access token for the victim, typically by having them sign in to an unrelated OAuth application on the same provider. On public providers, registering that application is self-service.
- The subject identifier the attacker&amp;#39;s client observes matches the one stored on the victim&amp;#39;s account. Google, GitHub, Okta and self-hosted OIDC servers in default configuration issue a subject that is stable across all clients and are directly affected. Microsoft Entra ID issues per-application subjects, so the match fails there unless `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled or `OAUTH_SUB_CLAIM` points at a globally stable claim such as `oid`.
- `OAUTH_ALLOWED_DOMAINS` is enforced on this endpoint but does not constrain the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rq84-p6rr-vf89</guid>
    </item>
    <item>
      <title>PYSEC-2026-3652 — Open WebUI: Account takeover via OAuth token exchange accepting tokens issued to any client</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-3652</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;The OAuth token exchange endpoint accepts a raw provider access token and validates it by calling the provider&amp;#39;s userinfo endpoint. A userinfo endpoint reports only that a token is valid, never which OAuth client it was issued to, and the endpoint performed no audience or client check of its own. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token&amp;#39;s user, including applications the operator does not control and has never authorised.&lt;/p&gt;
&lt;p&gt;## Preconditions&lt;/p&gt;
&lt;p&gt;- `ENABLE_OAUTH_TOKEN_EXCHANGE=True`. Disabled by default, so a stock deployment is not affected.
- The victim already has an Open WebUI account. The endpoint does not create users.
- The attacker can obtain a provider access token for the victim, typically by having them sign in to an unrelated OAuth application on the same provider. On public providers, registering that application is self-service.
- The subject identifier the attacker&amp;#39;s client observes matches the one stored on the victim&amp;#39;s account. Google, GitHub, Okta and self-hosted OIDC servers in default configuration issue a subject that is stable across all clients and are directly affected. Microsoft Entra ID issues per-application subjects, so the match fails there unless `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled or `OAUTH_SUB_CLAIM` points at a globally stable claim such as `oid`.
- `OAUTH_ALLOWED_DOMAINS` is enforced on this endpoint but does not constrain the…&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;The OAuth token exchange endpoint accepts a raw provider access token and validates it by calling the provider&amp;#39;s userinfo endpoint. A userinfo endpoint reports only that a token is valid, never which OAuth client it was issued to, and the endpoint performed no audience or client check of its own. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token&amp;#39;s user, including applications the operator does not control and has never authorised.&lt;/p&gt;
&lt;p&gt;## Preconditions&lt;/p&gt;
&lt;p&gt;- `ENABLE_OAUTH_TOKEN_EXCHANGE=True`. Disabled by default, so a stock deployment is not affected.
- The victim already has an Open WebUI account. The endpoint does not create users.
- The attacker can obtain a provider access token for the victim, typically by having them sign in to an unrelated OAuth application on the same provider. On public providers, registering that application is self-service.
- The subject identifier the attacker&amp;#39;s client observes matches the one stored on the victim&amp;#39;s account. Google, GitHub, Okta and self-hosted OIDC servers in default configuration issue a subject that is stable across all clients and are directly affected. Microsoft Entra ID issues per-application subjects, so the match fails there unless `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled or `OAUTH_SUB_CLAIM` points at a globally stable claim such as `oid`.
- `OAUTH_ALLOWED_DOMAINS` is enforced on this endpoint but does not constrain the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-3652</guid>
    </item>
  </channel>
</rss>
