CVE-2026-45401 is a server-side request forgery vulnerability in Open WebUI prior to version 0.9.5. The issue is caused by incomplete URL validation in validate_url() in backend/open_webui/retrieval/web/utils.py: only the initially supplied URL is checked against private-address and metadata-address restrictions. Downstream HTTP clients used by the application, including requests, aiohttp, and LangChain's WebBaseLoader, follow HTTP 3xx redirects by default and do not re-validate the redirect destination. As a result, an authenticated user can supply an attacker-controlled public URL that responds with a redirect to an internal or otherwise blocked target such as 127.0.0.1, 169.254.169.254, or RFC1918 space. Open WebUI then fetches the redirected resource and returns the response body through affected application routes including /api/v1/retrieval/process/web, /api/v1/images/... endpoints, /api/chat/completions when using an image_url content part, and other routes that invoke the same helper logic.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository contains a single Bash exploit script, exploit_ssrf.sh, targeting Open WebUI v0.9.4. It is a real exploit rather than a detector: it performs authenticated POST requests against two application endpoints to exploit SSRF via HTTP redirect handling. The script requires only a regular user account JWT, not admin privileges, and an attacker-controlled public redirect service. The core weakness described in the script is that Open WebUI validates the initial public URL hostname but then follows a 302 redirect server-side to an internal target, enabling SSRF. The repository structure is minimal: one Bash file with environment-variable configuration, two curl-based exploit paths, and output formatting. No auxiliary code is included beyond references to an external redirect server. The first exploit path, labeled Vector A, sends a POST request to /api/v1/retrieval/process/web?process=false with JSON containing the attacker redirect URL. According to the script comments, the backend validate_url() check is applied only to the initial URL, while requests.get() follows the redirect, allowing server-side access to internal resources and potentially returning readable content to the attacker. This is the stronger exfiltration path. The second path, Vector B, sends a POST request to /api/chat/completions with a message containing an image_url object pointing to the same redirect URL. The script notes that convert_url_images_to_base64() and get_image_base64_from_url() ultimately fetch the URL with redirect following enabled via aiohttp, causing the server to retrieve the redirected internal resource and incorporate the body into downstream LLM processing. This is described as semi-blind because the attacker may get only partial or indirect visibility into the fetched content, though server-side fetch can be confirmed via redirect server logs. Overall, the exploit provides two SSRF primitives against Open WebUI: a more direct retrieval/read vector and a secondary image-fetch vector embedded in chat completion processing. The attack surface is web-based and network-reachable, with the main fingerprintable targets being the Open WebUI API endpoints and the attacker-controlled redirect URL.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.