Open WebUI RAG fetch: a redirect that reaches cloud-metadata credentials

What is this?

On June 30, 2026, an advisory was published for Open WebUI, one of the most widely deployed self-hosted front-ends for local and API-backed language models. The issue is a server-side request forgery (SSRF) weakness in the web-retrieval feature: the endpoint that fetches a user-supplied URL to feed a retrieval-augmented-generation pipeline applied its safety filter only to the URL the caller typed, and not to where that URL redirected. An authenticated user could therefore point the server at a page they control, have it answer with an HTTP redirect to an internal address, and let Open WebUI follow that redirect straight to a cloud metadata endpoint. It is classed as CWE-918 (SSRF) and affects every version prior to 0.6.27, where it is fixed.

This is not a prompt-level attack and not a model jailbreak. It is a classic web-application SSRF that happens to live inside an LLM tool — the kind of surface that grows every time a chat front-end is handed the ability to fetch arbitrary URLs on behalf of a user.

How it works

Open WebUI’s retrieval endpoint accepts a URL, fetches the page server-side, and hands the text to the RAG pipeline. To stop that fetch from reaching internal systems, the code ran a block/allow filter over the requested host. The gap is that the check ran once, against the caller’s original URL, and then the underlying HTTP client was allowed to follow redirects with no re-validation.

An attacker with an authenticated session submits a URL to a server they run. That server replies with a 3xx redirect whose Location header points at a link-local or internal target — for example the cloud instance metadata service on 169.254.169.254, or the equivalent hostname on GCP, Azure or Alibaba Cloud. Because the filtering logic validated only the first hop and the metadata addresses were not in the default blocklist, the client happily issued the second request and returned the response body to the caller. On a cloud host without hardened metadata access, that body can include the instance’s IAM credentials, turning a read-only fetch feature into a path to cloud secrets. The reported impact is limited to information disclosure (confidentiality), with a network vector but a privilege requirement — the attacker needs a valid account able to call the retrieval endpoint. We are deliberately not publishing a ready-to-fire redirector configuration here; the mechanism is the lesson, not a payload.

Why it matters

Open WebUI is a default choice for teams that want a private chat interface over Ollama or a hosted API, and a large number of those instances run on cloud VMs. Two facts make the bug worth attention despite its moderate severity score. First, the payoff is credential theft: a successful redirect to an unprotected metadata service can hand over instance-role credentials, which is a foothold far more valuable than the fetch itself. Second, the pre-condition — an authenticated user who can reach the retrieval feature — is weaker than it sounds in the many deployments that self-serve signups or share a single low-trust tenant. Related SSRF-to-metadata patterns in the same ecosystem, from an inference-server image loader that pulled cloud metadata to MCP servers that reach the instance metadata service, point at the same lesson: any LLM component allowed to make outbound requests inherits every ordinary SSRF risk, and the internet is full of exposed self-hosted LLM front-ends that never expected to be reachable.

Defenses

Upgrade Open WebUI to 0.6.27 or later. This is the primary fix: the patch adds a default block list covering link-local and cloud-metadata addresses, and resolves redirect targets to their IP before the client is allowed to follow them, so a hostile Location header is re-checked instead of trusted.

Beyond patching, harden the environment the front-end runs in. On AWS, require IMDSv2 with a hop limit of one so a basic SSRF cannot read instance credentials; the other major clouds have equivalent metadata-hardening controls. Restrict egress from the Open WebUI workload so it cannot reach 169.254.169.254, other link-local ranges, or internal management networks regardless of how a request is shaped, ideally through an egress proxy that blocks private and link-local destinations. Where upgrading is not immediate, the fixed release exposes a WEB_FETCH_FILTER_LIST control you can set to deny metadata hostnames and RFC 1918 ranges, and you can gate or disable the retrieval endpoint for untrusted user tiers at the reverse proxy. Finally, rotate any instance credentials that could have been exposed before the patch, and treat authenticated access as a privilege: signups that anyone can complete turn a “needs an account” bug into an open one.

For detection, alert on outbound connections from the Open WebUI process to link-local or metadata addresses, and correlate retrieval-endpoint requests with the egress destinations that follow them — a fetch to an external URL immediately followed by a metadata response is the signature to watch for. Cloud audit logs will show instance-role credentials being used shortly after a suspicious retrieval call.

Status

Item	Detail
Affected	Open WebUI, all versions prior to 0.6.27
Component	/api/v1/retrieval/process/web web-retrieval endpoint (RAG)
Fixed in	Open WebUI 0.6.27 (commit 02238d3)
Weakness	CWE-918, Server-Side Request Forgery via redirect Location
Impact	Information disclosure — confidentiality; network vector, low privileges required
Severity	CVSS 4.0 5.3 (Medium); site rating: medium
Reference	CVE-2026-56399 (published 2026-06-30); advisory GHSA-82r6-c5jm-f3mw