CVE-2026-88001 in Open WebUI
Summary
by MITRE • 09/09/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified within Open WebUI versions ranging from 0.9.5 to 0.11.1 represents a critical server-side request forgery flaw rooted in the improper handling of HTTP redirect responses during web fetch operations. As an extensible and self-hosted artificial intelligence platform, Open WebUI relies on external data ingestion mechanisms such as web search integration, URL processing tools, and image fetching capabilities to function effectively. These features often require the backend server to retrieve content from user-provided or system-generated URLs. The core technical flaw lies in the behavior of the aiohttp library when configured with the AIOHTTP_CLIENT_ALLOW_REDIRECTS setting enabled. Under this configuration, while initial requests are subject to security filters including WEB_FETCH_FILTER_LIST and private-address controls designed to block access to internal networks, loopback interfaces, or cloud metadata services, these restrictions were not reapplied after an HTTP redirect occurred. Consequently, if a target URL returned a 3xx status code pointing toward a restricted destination, the application would follow that redirection without re-evaluating it against the security policy, effectively bypassing the intended access controls.
This architectural oversight allows authenticated users to manipulate fetch paths by leveraging intermediate URLs or proxies that redirect traffic to prohibited destinations. By crafting requests that trigger such redirects, an attacker can route sensitive data through allowed endpoints into internal services. The operational impact is severe, as it enables unauthorized access to cloud metadata services which often contain authentication tokens and configuration secrets essential for infrastructure security. Furthermore, the vulnerability facilitates server-side request forgery attacks against private networks and loopback interfaces, potentially allowing attackers to interact with internal applications or databases that are not exposed to the public internet but remain accessible from within the host network. This capability can lead to data exfiltration, unauthorized administrative actions, or further lateral movement within the compromised environment depending on what services reside behind these restricted addresses.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving improper restriction of web fetches based on IP address or domain name. It also maps to MITRE ATT&CK technique T1504.003 Web Service Discovery, as the attacker utilizes the application's own functionality to probe and access internal network resources that are typically hidden from external view. The failure to enforce security policies consistently across all stages of a request lifecycle, including redirects, is a common pattern in SSRF vulnerabilities where developers assume initial validation provides sufficient protection without considering state changes during protocol interactions like HTTP redirections.
To mitigate this vulnerability, organizations running Open WebUI must upgrade immediately to version 0.11.1 or later, which addresses the logic error by ensuring that security filters are reapplied after every redirect step in the fetch process. For environments where upgrading is not immediately feasible, administrators should consider disabling the AIOHTTP_CLIENT_ALLOW_REDIRECTS setting if web fetching functionality does not strictly require following redirects, thereby preventing the attack vector entirely. Additionally, implementing a robust network-level firewall or reverse proxy configuration that blocks outbound connections to private IP ranges and cloud metadata endpoints can provide an additional layer of defense in depth. Regular security audits focusing on external-facing services that perform server-side requests are recommended to identify similar patterns where input validation is not consistently enforced throughout the entire request handling lifecycle.