What was observed is the reachability and the read-back. No specific credential or secret was retrieved from the Azure platform channel during this investigation, and this advisory does not claim one. Deployments not hosted on Azure are unaffected for the platform-channel address, and deployments running with local web fetch enabled were never protected by this screen in any version.
Fix
Fixed in https://github.com/open-webui/open-webui/pull/27823. Address screening no longer rests on the library's notion of a globally routable address alone: a default block list of reserved and internal-purpose ranges is applied to every resolved address, at URL validation and again at connection time on both HTTP transports, so it also covers redirect hops and DNS rebinding. Operators can extend the list through WEB_FETCH_FILTER_LIST, which is merged with the defaults and cannot remove them.
Root cause
backend/open_webui/retrieval/web/utils.py: the shared address screen used by every server-side fetch.
POST /api/v1/retrieval/process/web: RAG URL ingestion, returns the fetched body to the caller.
POST /api/v1/retrieval/process/web/search: web search, fetches each result.
The code ships in every build, so no optional component or feature flag limits which installations carry it.
The screen answered one question, whether an address is globally routable, and treated that answer as a proxy for whether the destination is external. Those are two different questions. The library classifies by IANA special-purpose registry membership, and the Azure platform channel is allocated out of ordinary public IPv4 space, so the library correctly reports it as global while in practice it is an internal endpoint of the host's own platform. Earlier hardening (GHSA-8x5v-cpv7-8jjp) extended the screen to unwrap IPv6 addresses that carry an IPv4 address inside them. That closed the encoded-address bypasses and left the underlying test unchanged, so an address that is public by registry and internal by convention still passed.
Proof of concept
As any verified user:
POST /api/v1/retrieval/process/web
{"url": "http://168.63.129.16/?comp=versions"}
On an affected version the address passes validation, the request is issued, and the response body is returned in the content field of the API response.
The screening code of each released version was exercised directly:
0.11.0: 168.63.129.16, ::ffff:0:169.254.169.254 and fec0::1 all pass validation.
0.11.1: all three are rejected, along with every alternative spelling of the same address (IPv4-mapped, IPv4-compatible, IPv4-translated, 6to4 and both NAT64 prefixes) and the obfuscated decimal, octal and hexadecimal forms. Ordinary public addresses continue to pass.
No request was issued to a live Azure platform channel. The read-back property was confirmed from the ingestion endpoint, which returns the fetched body to the caller in its response.
Credits
@NaorYaa reported that the Azure platform channel remained reachable after the previous hardening, and demonstrated the same gap for the IPv4-translated and IPv6 site-local ranges.