CVE-2026-88001: 
Python vulnerability analysis and mitigation

CVE-2026-88001 is a Server-Side Request Forgery (SSRF) vulnerability in Open WebUI, a self-hosted AI platform, where server-side web fetches fail to reapply WEB_FETCH_FILTER_LIST or private-address controls to HTTP redirect destinations when AIOHTTP_CLIENT_ALLOW_REDIRECTS is enabled. It affects Open WebUI versions >= 0.9.5 and <= 0.11.0 (the redirect-following setting was introduced in 0.9.5). The vulnerability was originally reported by @arpitjain099 and @Classic298, published to the GitHub Advisory Database on September 9, 2026, and fixed in version 0.11.1. It carries a CVSS v3.1 base score of 5.0 (Medium) (Github Advisory, Open WebUI Advisory).

The root cause (CWE-918: Server-Side Request Forgery) lies in how Open WebUI's two SSRF controls — the operator-configured WEB_FETCH_FILTER_LIST and a private-address check — were each applied only to the originally submitted URL, not to subsequent HTTP redirect destinations. The WEB_FETCH_FILTER_LIST was evaluated inside validate_url(), which runs once at submission time, so redirect hops never passed through it. The private-address check was placed inside the aiohttp resolver (_SSRFSafeResolver), but aiohttp resolves IP-literal hosts (e.g., http://169.254.169.254/) internally without invoking the resolver, meaning the check was silently skipped for those addresses. Exploitation requires: (1) AIOHTTP_CLIENT_ALLOW_REDIRECTS=true (non-default), and (2) an authenticated account with access to any URL-fetching feature (web search, URL ingestion, page-fetch tool, or chat image URLs). The fix in PR #27823 replaced _SSRFSafeResolver with _SSRFSafeConnector, which hooks _resolve_host to cover IP-literal shortcuts, and moved filter-list evaluation to per-request hooks (connect() for aiohttp, send() for the requests adapter) so every redirect hop is checked (Open WebUI Advisory, Fix PR).

An authenticated user can cause the Open WebUI server to issue requests to operator-excluded hosts, loopback addresses, RFC1918 private ranges, and cloud metadata endpoints (e.g., 169.254.169.254 for AWS/GCP, fd00:ec2::254, metadata.google.internal, metadata.azure.com) — all of which appear blocked in the default configuration but are reachable via redirect. On requests-based fetch paths, the response body is returned directly to the caller (e.g., via the page-fetch tool or URL ingestion endpoint), enabling direct exfiltration of internal service responses. On aiohttp-based paths, fetched content can reach web search results, retrievable knowledge collections, or model input as base64-encoded chat image data, potentially exposing sensitive internal or cloud infrastructure metadata to the attacker (Open WebUI Advisory, Github Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a non-default configuration (AIOHTTP_CLIENT_ALLOW_REDIRECTS=true) and an authenticated account, which limits the attack surface; however, no knowledge of internal hostnames is needed since cloud metadata addresses are fixed and well-known (Github Advisory, Feedly).

1. Verify preconditions: Confirm the target Open WebUI instance is running a version between 0.9.5 and 0.11.0 and has AIOHTTP_CLIENT_ALLOW_REDIRECTS=true set in its environment configuration.
2. Obtain authenticated access: Log in to the Open WebUI instance with any valid user account (no elevated privileges required).
3. Set up a redirect server: Host a publicly accessible HTTP server (or use a redirect service) that issues an HTTP 301/302 redirect to a target internal address, such as http://169.254.169.254/latest/meta-data/ (AWS IMDSv1) or http://127.0.0.1:<internal-port>/.
4. Trigger a server-side fetch: Use one of the vulnerable fetch paths to submit the redirect server's URL to Open WebUI — for example, ingest the URL into a knowledge collection, use the built-in page-fetch tool, submit it as a web search result URL, or embed it as an image URL in chat.
5. Receive exfiltrated content: On requests-based paths, the response from the internal redirect destination is returned directly in the API response or handed to the AI model. On aiohttp-based paths, the content appears in web search results, a retrievable collection, or as base64 image data in the chat response (Open WebUI Advisory, Github Advisory).

• Network: Outbound HTTP requests from the Open WebUI server to 169.254.169.254, fd00:ec2::254, 100.100.100.200, metadata.google.internal, metadata.azure.com, loopback (127.0.0.1), or RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) — especially following an initial request to an external URL.
• Network: HTTP redirect chains observed in server egress traffic where the initial destination is a public host but the final connection target is an internal or metadata address.
• Logs: Open WebUI application logs showing fetch requests to external URLs that are immediately followed by connections to internal addresses; absence of Blocked by filter list or Blocked non-global address log warnings for requests to known-excluded hosts (indicating the filter was bypassed).
• Logs: URL ingestion or page-fetch tool API calls with external URLs that return responses containing cloud metadata content (e.g., IAM role names, instance IDs, tokens).
• Application Behavior: Knowledge collections or web search results containing content that appears to originate from internal services or cloud metadata endpoints rather than the submitted public URL (Open WebUI Advisory).

Upgrade Open WebUI to version 0.11.1 or later, which fixes the vulnerability by applying both the WEB_FETCH_FILTER_LIST and private-address checks to every redirect hop on all fetch paths (Open WebUI Release, Fix PR). If an immediate upgrade is not possible, set AIOHTTP_CLIENT_ALLOW_REDIRECTS=false (the default) to prevent redirect following entirely, which eliminates the vulnerable code path. As an additional defense-in-depth measure, enforce network-level egress controls to block the Open WebUI server from reaching cloud metadata endpoints (169.254.254.254, fd00:ec2::254, etc.) and private IP ranges. Note that for deployments routing outbound fetches through a forward proxy, the private-address check in 0.11.1 still sees the proxy's address rather than the final destination, so destination restrictions must also be enforced at the proxy level (Github Advisory).

The vulnerability was credited to two independent reporters — @arpitjain099 (excluded-host list bypass) and @Classic298 (private-address check bypass via aiohttp's IP-literal resolver shortcut) — who also authored the fix (Open WebUI Advisory). The Open WebUI maintainers included a security advisory note in the v0.11.1 release recommending that production deployments update at their earliest convenience (Open WebUI Release). No significant broader media coverage or notable social media commentary has been identified beyond standard vulnerability database aggregation.