Open WebUI CVE-2026-87999

Requires a valid Open WebUI user account (any role; PR:L in CVSS). The web retrieval endpoints POST /api/v1/retrieval/process/web and POST /api/v1/retrieval/process/web/search must be enabled (the default state). The most impactful exploitation path requires deployment on Microsoft Azure, where 168.63.129.16 is reachable from every VM on the wire-link network. On non-Azure deployments, 168.63.129.16 is not reachable from the host, so that specific target is unavailable; however, other special-use ranges covered by the fix (multicast, 6to4 relay, IPv6 site-local, NAT64) may be reachable depending on network topology, giving reduced but non-zero SSRF capability in other environments. No user interaction is required beyond issuing the API call. ENABLE_LOCAL_WEB_FETCH=false (the default) does not block 168.63.129.16 in pre-patch versions because Python classifies it as globally routable.

The CVSS 3.1 base score of 7.1 with vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N is well-calibrated. AC:H reflects the Azure-deployment-specific condition - on non-Azure or on-premises instances, 168.63.129.16 is not reachable, dramatically reducing real-world exposure. PR:L confirms that a valid user account is required, limiting the attack surface to trusted-but-adversarial users or compromised accounts. The Scope:Changed metric is appropriate because successful exploitation reaches beyond the Open WebUI process into Azure platform infrastructure, potentially yielding VM identities, managed-identity tokens, or certificates. EPSS data is not provided, and the vulnerability is not listed in CISA KEV. No public exploit identified at time of analysis. In practice, risk is high for Azure-hosted Open WebUI deployments where multi-tenant or less-trusted user access is permitted; for on-premises or non-Azure cloud deployments the practical risk is substantially lower. The embedded-IPv4-in-IPv6 bypass vectors (also fixed in 0.11.1) are a sophistication indicator that suggests the researcher performed thorough protocol-level analysis.

An authenticated attacker with a low-privilege Open WebUI account on an Azure-hosted instance submits POST /api/v1/retrieval/process/web with a target URL resolving to 168.63.129.16 or an equivalent IPv6-encoded form (e.g., ::ffff:168.63.129.16). The server fetches the Azure platform channel, which returns VM metadata, managed identity tokens, or internal certificates depending on the path requested. The attacker uses the returned content - visible in the retrieval response - to escalate privileges within the Azure subscription or pivot to other Azure resources accessible via the acquired token. No public proof-of-concept is identified, but the attack pattern is well-understood and straightforward for anyone familiar with Azure IMDS abuse.