Jul 7, 2026·6 min read·3 visits
Authenticated users can exploit a blind SSRF vulnerability in Open WebUI versions 0.7.2 and below via the image-edit endpoint. This allows scanning of the local address space, port discovery, and interaction with internal endpoints such as local databases or cloud metadata services.
Open WebUI versions 0.7.2 and below contain a blind Server-Side Request Forgery (SSRF) vulnerability. The flaw exists within the image editing router, specifically inside the /api/v1/images/edit endpoint. An authenticated attacker with low privileges can exploit this endpoint to initiate asynchronous HTTP GET requests to local, private, or internal network services, mapping system resources and bypassing boundary restrictions.
Open WebUI is an offline-capable, self-hosted user interface designed for interacting with local and remote artificial intelligence models. To enhance user interaction, the platform features multiple utility routers, including an image processing service. The image processing router exposes endpoints that support uploading, downloading, and editing user-provided images alongside prompt directives.
A technical assessment revealed a blind Server-Side Request Forgery (SSRF) vulnerability within the /api/v1/images/edit endpoint. When an authenticated, low-privileged user submits a request to modify an image, they can supply an arbitrary HTTP or HTTPS URL as the image source. The server attempts to retrieve the image resource directly from the user-specified host.
Because the backend does not enforce destination access controls, resolving hostnames are permitted to target internal network interfaces. This includes loopback addresses, local private subnets (RFC 1918), and link-local structures. This analysis describes the root cause, exploitation methodology, and complete mitigation path.
The underlying defect resides in how the image retrieval routine validates target strings. In the vulnerable application state, the image_edits router handles POST requests by reading parameters through an EditImageForm schema. The image property accepts either base64-encoded binary data or a standard URI string.
When a URI is identified, the backend invokes a nested asynchronous function named load_url_image(data). This function is designed to check if the input data begins with standard web protocol prefixes, specifically http:// or https://. Once confirmed, the endpoint executes an unconditional HTTP GET request to fetch the image.
The system fails to validate the resolved IP address of the target destination prior to connection initiation. Standard DNS resolution is performed dynamically during the client connection lifecycle. This permits the resolution of loopback ranges, such as 127.0.0.1, and cloud infrastructure endpoints, such as the 169.254.169.254 metadata address.
Furthermore, the endpoint handles connection errors by propagating raw exception text back to the client. When a targeted local port is closed, the connection attempt is rejected instantly, triggering a database or driver error. When a port is open but non-responsive, the system eventually times out. These distinct response patterns allow an attacker to perform reliable port scanning of host network services.
The vulnerable code path is located in backend/open_webui/routers/images.py inside the nested load_url_image utility function. The implementation lacks destination checks and executes standard synchronous HTTP transactions wrapped inside an asynchronous executor.
# Vulnerable code structure in backend/open_webui/routers/images.py
async def load_url_image(data):
if data.startswith("data:"):
return data
# The function only verifies the schema prefix
if data.startswith("http://") or data.startswith("https://"):
# Synchronous requests call executed unconditionally within a thread
r = await asyncio.to_thread(requests.get, data)
r.raise_for_status()
image_data = base64.b64encode(r.content).decode("utf-8")
return f"data:{r.headers['content-type']};base64,{image_data}"The patched implementation mitigates this by routing connections through a dedicated verification step prior to launching the network transaction. It invokes validate_url(data) to block loopback and private subnets, and introduces an SSRF-safe session handler.
# Patched secure implementation in backend/open_webui/routers/images.py
async def load_url_image(data):
if data.startswith('data:'):
return data
if data.startswith('http://') or data.startswith('https://'):
# Pre-resolve and validate destination host against blacklisted subnets
await asyncio.to_thread(validate_url, data)
# Enforce connect-time verification preventing DNS rebinding and redirection attacks
async with get_ssrf_safe_session() as session:
async with session.get(
data, ssl=AIOHTTP_CLIENT_SESSION_SSL, allow_redirects=AIOHTTP_CLIENT_ALLOW_REDIRECTS
) as r:
r.raise_for_status()
image_data = base64.b64encode(await r.read()).decode('utf-8')
return f'data:{r.headers["content-type"]};base64,{image_data}'In the secure version, the validate_url helper prevents standard private ranges from being requested. Furthermore, get_ssrf_safe_session leverages custom socket resolution policies. This guarantees that even if a DNS entry is updated during connection establishment (DNS rebinding), the resulting IP is re-evaluated before any bytes are transmitted.
To exploit this vulnerability, an attacker must first obtain verified credentials for the Open WebUI instance. Once authenticated, the attacker extracts the Bearer token to authorize API requests. The attacker targets the /api/v1/images/edit endpoint, crafting an payload that specifies a local network target.
By systematically incrementing the port number or IP address in the image parameter, the attacker maps the local environment. When a connection is attempted to a closed local port, the endpoint returns an HTTP 400 response indicating a connection failure. When the target port is open, the connection succeeds or times out based on service response behavior, enabling detailed network fingerprinting.
The following curl request demonstrates how an attacker initiates a port-scan probe targeting a local service on port 8080:
curl -X POST http://localhost:3000/api/v1/images/edit \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"form_data": {
"image": "http://127.0.0.1:8080/",
"prompt": "security-poc"}
}'> [!NOTE] > The raw exception messages returned inside the JSON response help the attacker distinguish between active, closed, and firewalled endpoints without triggering deep host security alerts.
The CVSS score for this vulnerability is assessed at 4.3 (Medium). Because the SSRF is blind, the attacker cannot read full raw responses from the internal services directly. However, the impact is significant when Open WebUI is co-located with sensitive, unauthenticated administrative tools.
In cloud deployments (such as AWS, GCP, or Azure), an attacker can target the Instance Metadata Service (IMDS). Under IMDSv1, requesting metadata endpoints requires no extra headers, allowing the attacker to retrieve sensitive configuration data, environment parameters, and temporary credentials.
In local environments, Open WebUI often runs adjacent to local container APIs or database instances like Ollama or Redis. An attacker can leverage this SSRF to execute unauthenticated commands, trigger container interactions, or deplete resources on internal database instances, widening the attack surface beyond the original container boundaries.
The primary remediation strategy is upgrading the Open WebUI instance to version 0.7.3 or later. This release enforces validation of all resolved IP addresses, blocking links targeting private IP addresses (RFC 1918) and link-local subnets before socket connection.
If upgrading is not immediately possible, administrators can mitigate the risk by modifying network configuration parameters. Setting the ENABLE_IMAGE_EDIT environment variable to False disables the affected endpoint completely, removing the attack surface.
Additionally, administrators can implement strict egress firewall policies on the Open WebUI container. Configuring rules to block outbound traffic from the container to private IP ranges and loopback interfaces protects internal infrastructure from SSRF exploitation.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Open WebUI open-webui | <= 0.7.2 | 0.7.3 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-918 |
| Attack Vector | Network (AV:N) |
| CVSS Score | 4.3 (Medium) |
| Exploit Status | Proof of Concept (PoC) Available |
| KEV Status | Not Listed |
| Impact | Low (Confidentiality) |
| Privileges Required | Low (PR:L) |
The web application server sends a request to an arbitrary destination provided by an untrusted user, bypasses access controls, or reaches internal systems.
CVE-2026-26192 is a high-severity Stored Cross-Site Scripting (XSS) vulnerability in Open WebUI prior to version 0.7.0. Authenticated users can modify chat history metadata to force document citations to render inside an HTML iframe configured with an insecure sandbox policy. By combining 'allow-scripts' and 'allow-same-origin', the sandbox boundary is neutralized. This allows scripts executing within the iframe to access the parent window's DOM, extract sensitive Web UI local storage keys (such as authentication JWTs), and perform state-changing actions on behalf of other users, including administrators.
CVE-2026-26193 is a stored Cross-Site Scripting (XSS) vulnerability in Open WebUI prior to version 0.6.44. The vulnerability arises because the rendering engine hardcodes insecure sandbox options on an iframe component used for response embeds, allowing attackers to execute JavaScript in the parent window origin.
An access control deficiency in the 9Router dashboard allows unauthenticated remote attackers to perform full CRUD operations on integrated AI providers, extract plaintext API keys, and access complete system conversation histories.
A DOM-based cross-site scripting (XSS) vulnerability exists in Craft CMS versions 4.0.0-RC1 through 4.17.15 and 5.0.0-RC1 through 5.9.22. The flaw resides within the CraftSupport widget's feedback search component, which fails to neutralize GitHub issue titles before rendering them into the administrator's control panel. An unauthenticated attacker can exploit this vulnerability by submitting a crafted issue to the public Craft CMS repository on GitHub.
CVE-2026-55793 is a DOM-based Stored Cross-Site Scripting (XSS) vulnerability affecting Craft CMS versions 5.0.0-RC1 through 5.9.22. An authenticated user with minimum Author privileges can store a malicious payload in an entry's title. When an administrator or high-privileged user performs a drag-and-drop operation under the modified entry in the structure table view, the unescaped payload is retrieved and concatenated into raw HTML, resulting in arbitrary JavaScript execution within the context of the administrative session.
Craft CMS versions 5.9.0 through 5.9.9 are vulnerable to authenticated Remote Code Execution (RCE). An attacker with control panel permissions to edit entries can inject malicious Twig templates into the client-side HTTP Referer header. During the post-save redirect sequence, the server evaluates this user-controlled header using an unsandboxed Twig rendering function, leading to arbitrary system command execution.