CVE-2026-54020: Open WebUI: DNS Rebinding SSRF Bypass

This is a time-of-check/time-of-use gap. The URL check resolves a hostname and rejects private, loopback and link-local addresses. Nothing ties that decision to the connection that follows, so the client does its own lookup. An attacker who runs the authoritative DNS for a submitted hostname, with TTL 0 and alternating answers, wins the race at the gap.

The affected fetches are the retrieval web loader (SafeWebBaseLoader), the content probe (get_content_from_url), the chat image_url fetch (get_image_base64_from_url), image editing (load_url_image) and the OAuth profile-picture fetch (_process_picture_url). The response comes back on most of them: as document content for retrieval, as the vision model's description for chat images and as a base64 profile picture for OAuth. Image editing is blind.

On the OAuth path the server also sends the user's OAuth access token as a Bearer header to the fetched URL, so a rebind hands the token to the internal target. That path needs OAuth login and a user-influenced OAUTH_PICTURE_CLAIM; for an existing account it needs OAUTH_UPDATE_PICTURE_ON_LOGIN, off by default.

Any ordinary account is enough. With IMDSv1 reachable, an attacker can take instance IAM credentials. Winning the race is not guaranteed, which keeps the score at medium.

Open WebUI 0.10.2 and earlier, in default configuration for the retrieval, chat image and image-edit paths. Admin-configured image-generation backends and the shared session pool are not affected. Check the version:

pip show open-webui

The OAuth profile-picture path matters only if OAuth login is configured.

Upgrade to 0.11.0:

pip install --upgrade open-webui==0.11.0

The fix (PRs 24759, 25775, 25960 and 26699) moves the check to the connection layer. A requests transport adapter resolves the hostname once and connects to that validated address, and an aiohttp resolver applies the same global-IP check. No configuration change is needed. For an additional layer, the sources imply blocking instance-metadata access from the host, but they list no formal workaround.

Look for retrieval, chat image_url or image-edit requests that name unfamiliar hostnames, then compare with your DNS and egress logs for connections from the Open WebUI host to 169.254.169.254, loopback or internal ranges. Repeated lookups of one hostname with different answers are a rebinding sign. On cloud hosts, check metadata-service logs for credential requests from the Open WebUI instance, and review use of its IAM role.

Summary

Open WebUI vetted user-supplied URLs by resolving the hostname once and rejecting private, loopback and link-local addresses, then let the HTTP client resolve that hostname again at connect time. An attacker who controls the authoritative DNS for a hostname they submit can answer with a public address during the check and an internal one at connect, so the fetch reaches an address the check was meant to block. Every user-reachable fetch gated by that check was affected, and most of them hand the internal response back to the attacker.

Preconditions

• An account on the instance. No admin rights and no non-default configuration.
• Control of the authoritative DNS for a hostname the attacker submits, serving a TTL of 0 and alternating answers.
• One of the affected entry points: URL ingest for retrieval, an image_url in a chat completion, image editing, or the OAuth profile-picture fetch.
• The OAuth path additionally needs OAuth login configured and a picture claim (OAUTH_PICTURE_CLAIM, default picture) the user can influence, which is the case on self-service OIDC providers and providers with a user-editable avatar URL. On an existing account it also needs OAUTH_UPDATE_PICTURE_ON_LOGIN, which is off by default. Deployments without OAuth are not affected on that path; the other paths need no configuration at all.

Impact

The server can be made to issue requests to addresses only it can reach: cloud instance metadata such as 169.254.169.254, loopback-bound admin APIs, and internal network services. The response comes back to the attacker on most paths, as document content on the retrieval path, described by the vision model on the chat image path, and base64-encoded into the profile picture on the OAuth path; the image-edit path is blind. On the OAuth path the server also forwards the OAuth access token as a Bearer header to the fetched URL, so a rebind hands that token to the internal target. On a cloud host with IMDSv1 reachable this is enough to take instance IAM credentials.

Exploitation depends on winning the gap between the two resolutions, which the attacker influences but does not fully control. Admin-configured image-generation backends and the shared session pool are not affected and deliberately keep the default client, since an administrator may legitimately point those at an internal host.

Fix

Fixed in v0.11.0 (#24759, #25775, #25960, #26699). The check now happens at the connection layer instead of ahead of it: a requests transport adapter resolves the hostname once and connects to that same validated address, and an aiohttp resolver applies the same global-IP check, exposed as a one-off session used by every fetch behind the URL check. Upgrading to v0.11.0 resolves this with no configuration change.

Root cause

Affected components:

• retrieval web loader (SafeWebBaseLoader)
• retrieval content probe (get_content_from_url)
• chat image fetch (get_image_base64_from_url)
• image edit fetch (load_url_image)
• OAuth profile-picture fetch (_process_picture_url)

The URL check resolved the hostname and inspected the resulting IP, but nothing tied that decision to the connection that followed: the HTTP client resolved the name again on its own, and the second answer was never inspected. The check was therefore an opinion about a past lookup rather than a constraint on the actual connection, which is what a rebinding DNS server defeats. The first connection-layer guard covered only the retrieval loader, leaving the sibling probe, image and OAuth fetches on default clients until each was reported in turn.

Credits

• @rezaduty — the rebinding time-of-check/time-of-use bypass and the retrieval loader path.
• @nikchillz — the retrieval content-probe path.
• @dhyabi2 — the chat image_url path, where the internal response is read back through the vision model.
• @geo-chen — the image-edit path.
• @bogdancherniy11-sudo — the OAuth profile-picture path, where the rebind also discloses the forwarded OAuth access token.