CVE-2026-34225: Open WebUI has Blind Server Side Request Forgery in its Image Edit Functionality

POST /api/v1/images/edit takes an image field in form_data. In backend/open_webui/routers/images.py, the function load_url_image trusts any HTTP or HTTPS URL and requests it with requests.get. Nothing blocks loopback, private ranges or cloud metadata addresses.

The response is never returned, so the attacker learns only whether the request succeeded or failed. By comparing those results across ports and hosts, a user with any valid account can map open ports on the server's network. The advisory notes a second step: if an open service exposes state-changing GET endpoints, the attacker may be able to trigger them.

The attacker needs a valid token and network access to Open WebUI. The CVSS score is 4.3, low confidentiality impact. It matters most when Open WebUI runs inside a private network next to internal admin panels, databases with HTTP interfaces or model servers.

The package data lists open-webui 0.7.2 and earlier as vulnerable. The vendor advisory page lists >= 0.6.35 and < 0.9.5 as affected, so use the vendor range. The code path is the image edit feature, reached at /api/v1/images/edit.

pip show open-webui

For Docker, read the version from the About page or the image tag.

The package data records no patched version. The vendor advisory page, read on 2026-10-25, lists 0.9.5 as the patched release. Upgrade to 0.9.5 or later.

pip install -U open-webui

The advisory gives no workaround. Its remediation direction is to block user-supplied URLs that point into local address space. You can approximate that today with egress rules on the host or container that deny traffic to private ranges and metadata addresses, except to services Open WebUI needs.

Search web server or reverse proxy logs for many POST /api/v1/images/edit calls from a single account in a short time, each with a different internal URL or port in the image field. Check outbound connections from the Open WebUI host to internal addresses and ports it does not normally use, such as sequential port probes. A burst of failed connections to private ranges that matches those requests is the pattern in the proof of concept.

Summary

There is a blind server side request forgery in the functionality that allows editing an image via a prompt. The affected function will perform a GET request on the URL provided by the user. There is no restriction on the domain of the provided URL allowing the local address space to be interacted with. Since the SSRF is blind (the response cannot be read) impact is port scanning of the local network because it can be confirmed if the port is open based on if the GET request failed.

Details

The vulnerability occurs here: https://github.com/open-webui/open-webui/blob/2b26355002064228e9b671339f8f3fb9d1fafa73/backend/open_webui/routers/images.py#L850-L916 Line 911 shows the user provided URL passed to the function load_url_image. Within this function on line 883 HTTP/HTTPs URLs are trusted blindly and called asynchronously with requests.get.

PoC

The vulnerability can be reproduced with the following curl command:

curl -X POST http://localhost:3000/api/v1/images/edit \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"form_data":{
    "image": "<url>",
    "prompt": "poc"}
  }'

Impact

Response differentials can be used to port scan the local network:

This can be automated to iterate through the entire port range to determine open ports. If the service running on an open port can be inferred the user may be able to interact with it in a meaningful way if the service offers any state changing GET request endpoints.

Remediation

Restrict provided URLs from local address space.