<?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:36 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-87996</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-87996</link>
      <description>&lt;p&gt;Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 until 0.11.1, SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py validated a user-controlled hostname in Python and then let the Playwright browser resolve it again in the sync and async request interceptors. An authenticated user controlling authoritative DNS could return a public address to validation and an internal address to the browser, exposing responses from internal services or cloud metadata through web search or URL ingestion. 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.9.6 until 0.11.1, SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py validated a user-controlled hostname in Python and then let the Playwright browser resolve it again in the sync and async request interceptors. An authenticated user controlling authoritative DNS could return a public address to validation and an internal address to the browser, exposing responses from internal services or cloud metadata through web search or URL ingestion. 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-87996</guid>
    </item>
    <item>
      <title>GHSA-4v28-j6q3-5m4r — Open WebUI: SSRF into internal services via DNS rebinding in the Playwright web loader</title>
      <link>https://db.gcve.eu/vuln/ghsa-4v28-j6q3-5m4r</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: open-webui&lt;/p&gt;
&lt;p&gt;## Summary
With the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.&lt;/p&gt;
&lt;p&gt;## Preconditions
- `WEB_LOADER_ENGINE=playwright`. This is not the default, and deployments on the default web loader are unaffected.
- A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`.
- Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.
- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.
- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.&lt;/p&gt;
&lt;p&gt;## Impact
An authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance…&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
With the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.&lt;/p&gt;
&lt;p&gt;## Preconditions
- `WEB_LOADER_ENGINE=playwright`. This is not the default, and deployments on the default web loader are unaffected.
- A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`.
- Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.
- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.
- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.&lt;/p&gt;
&lt;p&gt;## Impact
An authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4v28-j6q3-5m4r</guid>
    </item>
  </channel>
</rss>
