Open WebUI server-side request forgery through unchecked HTTP redirect destinations

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.5 until 0.11.1, server-side web fetches did not reapply WEB_FETCH_FILTER_LIST or private-address controls to HTTP redirect destinations when AIOHTTP_CLIENT_ALLOW_REDIRECTS was enabled. An authenticated user could redirect the aiohttp and requests fetch paths to excluded hosts, loopback, private networks, or cloud metadata services and route resulting content into web search, URL ingestion, page-fetch tools, or chat image processing. This issue is fixed in version 0.11.1.

• The open-webui package from vendor open-webui is affected in the range >= 0.9.5, < 0.11.1.
• The vendor advisory expresses the same scope as releases from 0.9.5 through 0.11.0.
• Exploitation of the vulnerable behavior requires AIOHTTP_CLIENT_ALLOW_REDIRECTS=true; its default is false, and deployments that have not changed this setting do not follow redirects as described by the advisory.
• 0.11.1 is the confirmed fixed release.
• Deployments using a forward proxy still need destination restrictions on the proxy itself because the private-address check may see the proxy address rather than the final destination.

Open WebUI performs server-side web fetches through paths using the aiohttp and requests clients. Two protections, WEB_FETCH_FILTER_LIST and private or internal address checks, were applied to the originally submitted URL but were not reapplied to the destination reached after an HTTP redirect.

The vulnerable behavior requires AIOHTTP_CLIENT_ALLOW_REDIRECTS=true and an authenticated account with access to a feature that causes the server to fetch a URL. Relevant paths include web search, URL ingestion into a collection, the built-in page fetch tool, and image URLs in chat. On aiohttp paths, the private-address check could also be bypassed when the redirect destination was an IP literal because the resolver was not invoked for that case. Client behavior differs by path, and the advisory does not demonstrate that every aiohttp path returns an attacker-controlled response verbatim to the requester.

The issue is reachable over the network by an authenticated user and does not require interaction from another user. An account of any role may be sufficient when it can access a feature that causes the server to fetch a URL, while AIOHTTP_CLIENT_ALLOW_REDIRECTS must be enabled.

An attacker can submit a URL that redirects to an excluded host, loopback, a private network, or a cloud metadata service. The vendor advisory documents a public proof of concept and states that the behavior was reproduced against affected source code. The supplied record does not establish exploitation in the wild.

An authenticated attacker can change the destination reached by Open WebUI server-side fetches, bypassing the intended protection provided by the excluded-host list and part of the private-address control. Depending on the client and fetch path, the technical result may include reading content from an excluded public host or placing content from internal resources into responses, collections, or model input.

The flaw can affect resources outside the scope of the URL initially submitted by the user, but it requires an authenticated account and a configuration that permits redirect following. The record provides no evidence that the issue enables data modification, code execution, or denial of service. The amount of data exposed depends on the server's network access, the client used, and proxy configuration.

The flaw can cause Open WebUI to send requests to hosts deliberately excluded by the operator and to internal resources reachable from the application server.

• Responses from excluded public hosts may be returned through some requests paths, including page fetch and URL ingestion.
• Some aiohttp paths may reach loopback, private networks, or cloud metadata endpoints and place retrieved content into web search responses, retrievable collections, or model input.
• The practical effect depends on the client, enabled features, outbound network permissions, and use of a forward proxy. The record does not establish data modification or service disruption.

1. Upgrade open-webui to the confirmed fixed release 0.11.1.
2. If an upgrade cannot be completed, set AIOHTTP_CLIENT_ALLOW_REDIRECTS=false or retain its default value so the affected paths do not follow HTTP redirects. This mitigation is based on the confirmed precondition in the advisory.
3. Do not rely solely on WEB_FETCH_FILTER_LIST or ENABLE_LOCAL_WEB_FETCH to protect an unfixed release because redirect destinations may bypass those controls.
4. For deployments using a forward proxy, enforce destination restrictions on the proxy to prevent connections to loopback, private networks, cloud metadata services, and other unauthorized destinations.
5. After upgrading, verify that web search, URL ingestion, page fetch, and chat image URL paths apply checks to every redirect hop.

1. Inventory deployments running the open-webui package and determine their installed versions, then compare them with the affected range in affected_summary.
2. Inspect the AIOHTTP_CLIENT_ALLOW_REDIRECTS setting. Deployments where it is enabled should receive priority review.
3. Identify accounts and roles that can use web search, URL ingestion, the built-in page fetch tool, or chat image URLs, because the advisory identifies these as paths that can reach the flaw.
4. If outbound HTTP or proxy telemetry is available, review redirects from user-supplied URLs to hosts in WEB_FETCH_FILTER_LIST, loopback, private addresses, or 169.254.169.254. This is precautionary behavioral review, not a confirmed IOC.
5. Review egress policy on any forward proxy used by the deployment. The absence of matching log records does not prove that a deployment is safe.