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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | < 0.10.0 | 0.10.0 |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
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?
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:
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
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0107 Exploitation for Defense Evasion Compliance Controls Affected
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 References
- github.com/open-webui/open-webui/commit/087878ce848a4d828012068b5997dac480f43656 x_refsource_MISC
- github.com/open-webui/open-webui/pull/25949 x_refsource_MISC
- github.com/open-webui/open-webui/releases/tag/v0.10.0 x_refsource_MISC
- github.com/open-webui/open-webui/security/advisories/GHSA-qg3f-8x3j-ggf2 x_refsource_CONFIRM
- github.com/advisories/GHSA-qg3f-8x3j-ggf2
- nvd.nist.gov/vuln/detail/CVE-2026-59223
Timeline
Related Vulnerabilities
CVE-2026-44551 9.1 open-webui: LDAP auth bypass — full account takeover
Same package: open-webui CVE-2026-45672 8.8 open-webui: code exec gate bypass via API endpoint
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui