Server-side request forgery in Open WebUI from open-webui exposes internal fetch responses

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.11.1, POST /api/v1/retrieval/process/web and POST /api/v1/retrieval/process/web/search in backend/open_webui/retrieval/web/utils.py treated Python's globally routable address classification as proof that a destination was external. An authenticated user could make an Azure-hosted instance fetch and return content from 168.63.129.16, the Azure platform channel, as well as other reserved ranges that the standard classification did not reject. This issue is fixed in version 0.11.1.

• The open-webui pip package is affected at versions < 0.11.1.
• The vendor advisory identifies 0.11.1 as the patched version. The status of every later or parallel branch is not established beyond that exact fixed release.
• Exposure to 168.63.129.16 requires the Open WebUI host to run on Azure. Other reserved-range exposure depends on whether the deployment can route to those destinations.
• The advisory states that the vulnerable code ships in every build and is not limited to an optional component. Deployments with ENABLE_LOCAL_WEB_FETCH=true intentionally bypass this address screen in every version; that is a separate exposure condition, not evidence that the deployment is protected.

The flaw is in the shared backend/open_webui/retrieval/web/utils.py component used by server-side web fetches. The earlier check used Python's globally routable address classification as a proxy for whether a destination was external. Those questions are not equivalent: some special-purpose ranges are classified as globally routable even though they can identify internal or platform-specific endpoints.

A user-controlled URL reaches POST /api/v1/retrieval/process/web for RAG URL ingestion or POST /api/v1/retrieval/process/web/search for web search. Both paths require an authenticated, verified account, but no administrator role or special workspace permission. If the destination passes validation, Open WebUI makes the request from the server and returns the response body through the API, with the fetched content also entering the RAG context.

The advisory states that the vulnerable code ships in every build and is not limited to an optional component. The Azure platform channel at 168.63.129.16 is a concrete example because it can be reached from Azure virtual machines even though the library classifies the address as global. The exact internal data available depends on deployment routing and the permissions of the reachable endpoint; the available evidence does not establish the full set of accessible content.

The flaw is reachable over the network through the two server-side web-fetch endpoints. An attacker needs an authenticated, verified account, but does not need an administrator role, special workspace permission, or interaction from another user. The record characterizes attack complexity as high, so exploitation is not an arbitrary request under every deployment condition.

The record states that a public exploit exists, and the advisory includes a proof of concept showing that the server can fetch a reserved destination and return the content to the caller. The advisory also states that no request was issued to a live Azure platform channel during the investigation. This confirms the application behavior but does not establish exploitation in deployed environments. Known-exploited status is not established by the supplied evidence.

The primary technical outcome is that Open WebUI makes an outbound GET request to a destination that should not have been treated as external and returns the response body to an authenticated user. This is SSRF across the application's intended trust boundary, with the main risk being loss of confidentiality from an internal service or cloud platform channel.

Exploitation requires an authenticated account, so this is not unauthenticated access. On Azure, a valid user may cause the host to reach the Azure platform channel; for other reserved ranges, the result depends on host routing. The record does not establish arbitrary writes, code execution, or retrieval of a specific credential, and it does not show that every deployment can reach the same set of internal resources.

• Authenticated users may read response bodies from internal-use destinations that the operator did not intend to expose through Open WebUI.
• On Azure, this includes the platform channel reachable from Azure virtual machines. Returned content could expose platform or host information, but the evidence does not identify a specific secret that was retrieved.
• Fetched content is also placed in the RAG context, extending the data boundary between the Open WebUI service and internal resources it can reach.
• Practical impact depends on account access, host routing, outbound network controls, and whether an operator-supplied filter covers the destination. The record does not establish that the flaw by itself causes availability loss or arbitrary code execution.

1. Upgrade the open-webui package to 0.11.1, the exact patched release identified by the advisory.
2. If an immediate upgrade is not possible, add explicit entries for relevant destinations to WEB_FETCH_FILTER_LIST, including 168.63.129.16 for Azure-hosted deployments, and enforce outbound network restrictions at the infrastructure layer. Treat this as temporary risk reduction and test it because older filtering behavior may not cover every address spelling or redirect path.
3. Do not enable ENABLE_LOCAL_WEB_FETCH as a workaround. That option intentionally disables the address screen and can make internal destinations reachable by design.
4. After patching, verify that address screening runs both during URL validation and when the connection is created, including redirect hops, proxy paths, DNS cache paths, and DNS rebinding. This confirms that the deployed code contains the relevant fix rather than only reflecting a changed package label.
5. Review request and response history for authenticated users that may have requested internal destinations. No specific IOC is provided by the advisory, so the absence of a particular log pattern does not rule out exposure.

• Inventory Open WebUI deployments and the open-webui package wherever server-side RAG URL ingestion or web search is enabled, then compare installed releases with the vendor's affected and fixed boundaries.
• Identify whether each host runs on Azure, including Azure virtual machines, AKS, Container Apps, or an equivalent environment, and determine whether it can route to 168.63.129.16 or other reserved ranges.
• Check ENABLE_LOCAL_WEB_FETCH and WEB_FETCH_FILTER_LIST. Enabling ENABLE_LOCAL_WEB_FETCH=true intentionally disables the address screen.
• Review authentication and request logs for calls to POST /api/v1/retrieval/process/web or POST /api/v1/retrieval/process/web/search carrying destinations that resolve to internal addresses, reserved ranges, or the Azure platform channel. This is an investigation lead, not a vendor-confirmed IOC.
• On patched deployments, test in a controlled environment that reserved destinations are rejected during URL validation and at connection time, including redirect and DNS-rebinding paths, while legitimate public destinations continue to work. Application logs may contain warnings such as Blocked by filter list or Blocked non-global address when logging is enabled. Absence of those messages does not prove that the deployment is safe.