CVE-2026-59223: Open WebUI: SSRF via web-fetch blocklist bypass

GHSA-qg3f-8x3j-ggf2 MEDIUM
Published July 9, 2026
CISO Take

Open WebUI's WEB_FETCH_FILTER_LIST — the hostname blocklist meant to stop the platform's web-fetch/RAG retrieval feature from reaching internal or forbidden hosts — compared entries against raw URL strings using non-label-boundary suffix matching, so an attacker could smuggle a blocked hostname into a URL path (e.g. as `!internal.example.com`) or exploit sibling-domain matching to slip past the filter entirely. Any authenticated low-privilege user (PR:L, no user interaction needed) can abuse this to make the Open WebUI backend fetch content from hosts the operator explicitly tried to block, which in self-hosted AI deployments frequently sit next to internal admin panels or cloud metadata endpoints — a classic SSRF pivot into the internal network, with confidentiality impact limited to what the fetched response reveals (CVSS 4.3, C:L/I:N/A:N). There's no public exploit or Nuclei template yet and it isn't in CISA KEV, and EPSS is low (0.00233, ~86th percentile), so this isn't an emergency, but with 130 other CVEs already recorded against this package and 0 downstream dependents tracked, treat it as a routine-but-real patch item. Upgrade to Open WebUI 0.10.0, which fixes the matching logic; until then, review your WEB_FETCH_FILTER_LIST configuration and add network-layer egress controls (block outbound access to link-local/metadata ranges and internal CIDRs from the Open WebUI host) so the application-layer filter isn't your only line of defense.

Sources: NVD GitHub Advisory EPSS CISA KEV ATLAS github.com/open-webui

What is the risk?

Medium severity, low complexity, low privileges required. The vulnerability is a protection-mechanism failure (CWE-693) in a hostname allow/deny check, not a memory-safety or auth flaw, so exploitation is a matter of crafting the right URL string rather than deep technical skill. Real-world risk hinges entirely on deployment context: instances that rely on WEB_FETCH_FILTER_LIST as their only control against reaching internal services (cloud metadata endpoints, internal APIs, admin interfaces) are exposed to SSRF-style data disclosure from any authenticated account. No public exploit code or scanner template exists yet and it's not in CISA KEV, keeping near-term opportunistic exploitation likelihood low, but the underlying bug class (blocklist bypass via string-matching edge cases) is easy to rediscover once the advisory is public.

How does the attack unfold?

Authenticated Access
Adversary obtains or already holds a low-privileged authenticated account on a self-hosted Open WebUI instance.
AML.T0012
Filter Bypass
Adversary crafts a URL exploiting non-label-boundary suffix matching or embeds a blocked hostname string in the path to evade the WEB_FETCH_FILTER_LIST check.
AML.T0107
SSRF Execution
The bypassed request causes the Open WebUI backend to fetch content from a host the administrator intended to block, such as an internal service or cloud metadata endpoint.
AML.T0049
Data Disclosure
The fetched response is surfaced back through the chat or RAG ingestion pipeline, leaking internal service data or credentials to the adversary.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip < 0.10.0 0.10.0
149.6K 4 dependents Pushed yesterday 81% patched ~6d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
4.3 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 13% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C Low
I None
A None

What should I do?

1 step
  1. Upgrade Open WebUI to version 0.10.0 or later, which fixes the WEB_FETCH_FILTER_LIST hostname matching to respect label boundaries. Until patched, do not rely on the filter list alone — enforce network-layer egress controls (firewall rules or an egress proxy) that block the Open WebUI host from reaching link-local/metadata addresses (169.254.169.254, etc.) and internal RFC1918 ranges. Audit and tighten any existing WEB_FETCH_FILTER_LIST entries, remove reliance on suffix-style hostname rules, and consider disabling the web-fetch/URL-ingestion feature entirely for deployments that don't need it. For detection, monitor outbound requests from the Open WebUI host for connections to internal IP ranges or metadata endpoints that fall outside expected external web-fetch traffic.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
MEASURE 2.7 - AI system security and resilience evaluation
OWASP LLM Top 10
LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-59223?

Open WebUI's WEB_FETCH_FILTER_LIST — the hostname blocklist meant to stop the platform's web-fetch/RAG retrieval feature from reaching internal or forbidden hosts — compared entries against raw URL strings using non-label-boundary suffix matching, so an attacker could smuggle a blocked hostname into a URL path (e.g. as `!internal.example.com`) or exploit sibling-domain matching to slip past the filter entirely. Any authenticated low-privilege user (PR:L, no user interaction needed) can abuse this to make the Open WebUI backend fetch content from hosts the operator explicitly tried to block, which in self-hosted AI deployments frequently sit next to internal admin panels or cloud metadata endpoints — a classic SSRF pivot into the internal network, with confidentiality impact limited to what the fetched response reveals (CVSS 4.3, C:L/I:N/A:N). There's no public exploit or Nuclei template yet and it isn't in CISA KEV, and EPSS is low (0.00233, ~86th percentile), so this isn't an emergency, but with 130 other CVEs already recorded against this package and 0 downstream dependents tracked, treat it as a routine-but-real patch item. Upgrade to Open WebUI 0.10.0, which fixes the matching logic; until then, review your WEB_FETCH_FILTER_LIST configuration and add network-layer egress controls (block outbound access to link-local/metadata ranges and internal CIDRs from the Open WebUI host) so the application-layer filter isn't your only line of defense.

Is CVE-2026-59223 actively exploited?

No confirmed active exploitation of CVE-2026-59223 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59223?

Upgrade Open WebUI to version 0.10.0 or later, which fixes the WEB_FETCH_FILTER_LIST hostname matching to respect label boundaries. Until patched, do not rely on the filter list alone — enforce network-layer egress controls (firewall rules or an egress proxy) that block the Open WebUI host from reaching link-local/metadata addresses (169.254.169.254, etc.) and internal RFC1918 ranges. Audit and tighten any existing WEB_FETCH_FILTER_LIST entries, remove reliance on suffix-style hostname rules, and consider disabling the web-fetch/URL-ingestion feature entirely for deployments that don't need it. For detection, monitor outbound requests from the Open WebUI host for connections to internal IP ranges or metadata endpoints that fall outside expected external web-fetch traffic.

What systems are affected by CVE-2026-59223?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, agent frameworks, self-hosted AI platforms.

What is the CVSS score for CVE-2026-59223?

CVE-2026-59223 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.22%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesagent frameworksself-hosted AI platforms

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, WEB_FETCH_FILTER_LIST matching compared configured host entries against URL strings and non-label-boundary suffixes, allowing path-based blocklist bypasses such as !internal.example.com in a URL path and sibling-domain matches that did not reflect the intended hostname policy. This issue is fixed in version 0.10.0.

Exploitation Scenario

An authenticated but low-privileged user of a self-hosted Open WebUI instance wants to reach an internal service the admin has blocklisted, such as a cloud metadata endpoint or an internal admin API. Instead of requesting the blocked host directly (which the filter would reject), they submit a URL to the web-fetch/RAG feature crafted to exploit the non-label-boundary suffix check — for example embedding the blocked hostname string as a path segment (`https://attacker.tld/!internal.example.com`) or using a sibling/lookalike domain the filter incorrectly treats as equivalent. The filter's string-based comparison fails to recognize the request as targeting a blocked host, so the Open WebUI backend issues the fetch on the attacker's behalf and returns the response content through the chat or RAG ingestion pipeline, leaking internal service data or metadata credentials to the user.

Weaknesses (CWE)

CWE-693 — Protection Mechanism Failure: The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Timeline

Published
July 9, 2026
Last Modified
July 24, 2026
First Seen
July 9, 2026

Related Vulnerabilities