# SSRF Open WebUI URL Loader Internal Target

- **Severity:** High
- **Signature ID:** `7b3f1c42-9d18-4a76-b0e5-2c94f8d61a3e`

## Summary

Open WebUI lets users hand it a URL to fetch content — web pages, YouTube transcripts, documents, plugins. An attacker with a valid account can abuse this to make the server fetch internal-only addresses instead, probing or reaching systems that should not be reachable from outside.

## How the attack works

An authenticated user submits a URL to one of Open WebUI's fetch endpoints, such as the RAG web loader, YouTube loader, document loader, pipeline install-from-URL, or knowledge file-add-from-URL. Instead of a normal public link, the URL points at a loopback address, a private (RFC1918/CGNAT) or link-local range, a cloud metadata IP, an internal DNS suffix, a DNS-rebinding domain, an obfuscated IP literal, or a non-HTTP scheme like file/gopher/dict/ldap. The server itself makes the request to that internal target on the attacker's behalf. Because this is blind SSRF, the attacker gets no response body back — the outgoing request is the only visible evidence, and success typically shows up indirectly through side effects (timing, error differences, or downstream impact) rather than returned data.

## Why it matters

An attacker with only application-level access can use the server as a proxy to reach internal services, cloud metadata endpoints, or local files that are otherwise not exposed to them, which can lead to credential theft, internal network mapping, or further compromise.

## What you can do

- Upgrade Open WebUI to v0.1.117 or later, which patches this issue (CWE-918).
- Restrict outbound network access from the Open WebUI host so it cannot reach cloud metadata endpoints, loopback, or other internal ranges it doesn't need.
- Review alerts against known benign cases, such as staff pasting real intranet/Confluence links or self-hosted setups using host.docker.internal or .local names, before treating a hit as malicious.
- If self-hosting, isolate the Open WebUI container/network so its fetch features cannot reach sensitive internal services even if abused.

## Known benign look-alikes

- A user legitimately pasting an intranet wiki, Confluence or internal docs URL (e.g. an RFC1918 address or a *.internal / *.local host) into the Open WebUI RAG web loader to summarise an internal page. This is the dominant benign case and the reason the rule reports rather than blocks.
- Self-hosted single-box deployments where an operator points the web loader or a pipeline install at a service on the same host or the same Docker network (host.docker.internal, a compose service name resolving under .local).
- Homelab / mDNS environments where genuine content is served from *.local names.
- Authorised penetration testing or vulnerability-scanner traffic against a known Open WebUI instance, which will produce exactly this signature by design.
- Internal CI smoke tests that exercise the retrieval/web endpoint against a loopback fixture server.

## References

- https://github.com/open-webui/open-webui/releases/tag/v0.1.117
- https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
- https://cwe.mitre.org/data/definitions/918.html

---
Source: https://www.netzilo.com/threats/open-webui-blind-ssrf