Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-09-09T22:18:48.930Z",
  "pubdate": "2026-09-09T22:18:48.930Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in Open WebUI versions 0.9.5 through 0.11.1 due to improper validation of HTTP redirect destinations.\nWhen AIOHTTP_CLIENT_ALLOW_REDIRECTS is enabled, the application fails to re-apply filtering logic—specifically WEB_FETCH_FILTER_LIST and private-address controls—to subsequent requests following a 3xx redirect.\nThis vulnerability allows an authenticated attacker to bypass security boundaries and force the server to perform arbitrary requests against internal network resources, loopback interfaces, or cloud metadata services (e.g., IMDS).\nThe impact includes unauthorized access to internal infrastructure, potential exfiltration of sensitive service credentials, and the ingestion of internal content into the AI processing pipeline.\nExploitation requires an authenticated user session to trigger web search, URL ingestion, or chat image processing tools.\nThe vulnerability is resolved in version 0.11.1, which mandates proper enforcement of security filters across all redirect chain members.",
  "technicalDetails": "The vulnerability stems from a flaw in the application's request processing logic involving the 'aiohttp' and 'requests' libraries. While Open WebUI implements security mechanisms, such as 'WEB_FETCH_FILTER_LIST' and private-address blocks, these filters are only applied to the initial request destination. When 'AIOHTTP_CLIENT_ALLOW_REDIRECTS' is configured as true, the underlying HTTP client libraries automatically follow 3xx redirect responses. The application logic fails to re-validate these secondary, location-header-derived URLs against the existing security policies.\nThe attack flow proceeds as follows: An authenticated user initiates a web search, page-fetch, or image-processing task by providing a malicious URL. The Open WebUI server initially validates the URL against the deny-list and private-address constraints, finding it safe (e.g., pointing to an external domain controlled by the attacker). Upon receiving the initial response, the attacker's server issues an HTTP 302 or 307 redirect pointing to an internal resource, such as 'http://127.0.0.1:8080' or a cloud provider's metadata endpoint (e.g., 'http://169.254.169.254').\nBecause the 'aiohttp' client follows the redirect automatically without re-invoking the internal filter mechanism, the server-side process fetches the sensitive content from the target internal host. The resulting data, such as internal service responses or cloud instance identity tokens, is then returned to the attacker through the Open WebUI interface, effectively bridging the gap between the internal network and the user-facing application.\nThis SSRF vector is particularly dangerous within cloud environments, as it allows attackers to query metadata services to retrieve IAM credentials, instance information, or other environmental configuration data stored in sensitive internal endpoints. Furthermore, by targeting loopback or local network addresses, an attacker can interact with services bound to the host that are otherwise inaccessible from the public internet. The lack of re-validation at each hop of the redirect chain creates a blind spot in the request lifecycle, ensuring that the initial safety check is insufficient for protecting the server against malicious redirection patterns."
}