# Open WebUI: Any authenticated user can reach the Azure platform channel via server-side web fetch

Open WebUI's SSRF screen trusted Python's is_global check, letting any authenticated user fetch Azure's internal platform channel 168.63.129.16 and read the response.

- Payout: Research
- Severity: high
- Program: Open WebUI
- Found by: NaorYaa
- Disclosed: 2026-09-10
- CVE: CVE-2026-87999
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-34r3-9m95-vq73
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-34r3-9m95-vq73
- Tags: area:cloud domain:cloud domain:web impact:internal-access kind:research platform:ghsa sev:high tech:azure tech:python technique:incomplete-fix technique:source-review vuln:ssrf

**Target:** Server-side URL fetch (RAG ingestion / web search) in Open WebUI backend
**Root cause:** The address screen equated Python's 'globally routable' classification with 'external destination'. 168.63.129.16 is allocated from public IPv4 space so the library reports it global, yet it is an internal Azure platform endpoint reachable from every Azure VM.
**Steps:**
1. Authenticate as any verified user (no admin role needed).
2. Ensure ENABLE_LOCAL_WEB_FETCH is default false and WEB_FETCH_FILTER_LIST empty.
3. Send `POST /api/v1/retrieval/process/web` with body `{"url": "http://168.63.129.16/?comp=versions"}`.
4. Address passes validation, server issues GET, response body returned in the `content` field and stored in RAG context.
5. Same gap applies to `::ffff:0:169.254.169.254` (IPv4-translated) and `fec0::1` (IPv6 site-local) on hosts that route them.
**How found:** Reporter noticed the Azure platform channel remained reachable after prior hardening (GHSA-8x5v-cpv7-8jjp) that only unwrapped IPv6-embedded IPv4 addresses. Realized the underlying test — is_global — was unchanged, and that registry-public-but-convention-internal addresses like 168.63.129.16 still pass; then tested IPv4-translated and IPv6 site-local ranges against the screening code of each release.
**Exploitation:** Any authenticated user submits a URL pointing at 168.63.129.16 (or IPv4-translated/site-local equivalents) to the RAG ingestion or web search endpoint; the server fetches it and returns the body to the caller, exposing the Azure platform channel's responses. Requires the Open WebUI host to run on Azure; no credential retrieval was demonstrated.
**Insight:** Cloud platform magic IPs (Azure 168.63.129.16, AWS/GCP metadata) live in ordinary public ranges, so 'is_global'/'is_public' checks never block them — enumerate per-cloud reserved addresses and add explicit block lists rather than trusting registry classification. Also re-test prior SSRF fixes: hardening that only unwraps encoded forms leaves the classification predicate itself intact.