CVE-2026-87999: Open WebUI SSRF leaks Azure platform

Q: Is CVE-2026-87999 actively exploited?

No confirmed active exploitation of CVE-2026-87999 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-87999?

Upgrade to Open WebUI 0.11.1 or later immediately — this is the only complete fix. Until patched, restrict egress from the Open WebUI host/container at the network layer (NSG/firewall) to block outbound access to 168.63.129.16 and other Azure platform-reserved ranges. If the web retrieval/search feature isn't business-critical, disable it for non-admin roles as a compensating control. Review retrieval request logs for `process/web` and `process/web/search` calls targeting internal or reserved IPs as a detection signal, and treat any hit as a confirmed exploitation attempt given there's no legitimate reason a user query would target that address.

Q: What systems are affected by CVE-2026-87999?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, web retrieval / ingestion, self-hosted LLM UI, cloud-hosted inference deployments.

Q: What is the CVSS score for CVE-2026-87999?

CVE-2026-87999 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.22%.

CISO Take

Open WebUI's web-retrieval feature (used to fetch and ingest URLs for RAG-style search) relied on Python's "globally routable" address check to decide what counted as an external destination, and that check missed several reserved ranges — including 168.63.129.16, Azure's internal platform communication channel. Any authenticated user, even one with low privileges, could point the retrieval endpoint at that address and get the backend to fetch and return its content, turning a RAG ingestion feature into an SSRF pivot into cloud infrastructure. There's no public exploit, no Nuclei template, and it isn't in CISA KEV, so this looks opportunistic rather than actively weaponized today — but the attack complexity (AC:H) mainly reflects that it only bites Azure-hosted instances, not that it's hard to execute once you know the target IP. With 168 other CVEs already recorded against this package and 3 downstream dependents, prioritize confirming your exposure. Patch to Open WebUI 0.11.1 or later, and if you're on Azure, verify no unexpected outbound requests to 168.63.129.16 have occurred via retrieval logs.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High severity (CVSS 7.1) but gated by authentication (PR:L) and high attack complexity (AC:H, since it depends on Azure hosting and knowledge of the platform channel address) — this is not a pre-auth, drive-by bug. Impact is confidentiality-heavy (C:H) with low integrity impact and no availability impact: a successful request discloses content from an internal/reserved address rather than granting code execution or full IMDS-style credential theft. No EPSS score, no CISA KEV listing, no public PoC or scanner template exist yet, so real-world exploitation likelihood is currently low — but SSRF-to-metadata-channel bugs are a well-understood class that gets weaponized quickly once researchers map out what 168.63.129.16 actually exposes on a given deployment.

How does the attack unfold?

Entry point

An authenticated, low-privileged Open WebUI user submits a crafted URL to the web retrieval endpoint (POST /api/v1/retrieval/process/web).

AML.T0049

Filter bypass

The backend's SSRF check, based only on Python's globally-routable address classification, fails to reject 168.63.129.16 and other reserved ranges.

Server-side fetch

The Azure-hosted Open WebUI server fetches content from the Azure platform channel on the attacker's behalf.

AML.T0075

Impact

The fetched internal content is returned to the attacker via the retrieval response, disclosing data outside the intended tenant boundary.

Entry point

An authenticated, low-privileged Open WebUI user submits a crafted URL to the web retrieval endpoint (POST /api/v1/retrieval/process/web).

AML.T0049

Filter bypass

The backend's SSRF check, based only on Python's globally-routable address classification, fails to reject 168.63.129.16 and other reserved ranges.

Server-side fetch

The Azure-hosted Open WebUI server fetches content from the Azure platform channel on the attacker's behalf.

AML.T0075

Impact

The fetched internal content is returned to the attacker via the retrieval response, disclosing data outside the intended tenant boundary.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	< 0.11.1	`0.11.1`
151.8K 3 dependents Pushed 7d ago 83% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 13% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC High

PR Low

UI None

S Changed

C High

I Low

A None

What should I do?

1 step

Upgrade to Open WebUI 0.11.1 or later immediately — this is the only complete fix. Until patched, restrict egress from the Open WebUI host/container at the network layer (NSG/firewall) to block outbound access to 168.63.129.16 and other Azure platform-reserved ranges. If the web retrieval/search feature isn't business-critical, disable it for non-admin roles as a compensating control. Review retrieval request logs for process/web and process/web/search calls targeting internal or reserved IPs as a detection signal, and treat any hit as a confirmed exploitation attempt given there's no legitimate reason a user query would target that address.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage RAG AML.T0049 - Exploit Public-Facing Application AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-87999?

Open WebUI's web-retrieval feature (used to fetch and ingest URLs for RAG-style search) relied on Python's "globally routable" address check to decide what counted as an external destination, and that check missed several reserved ranges — including 168.63.129.16, Azure's internal platform communication channel. Any authenticated user, even one with low privileges, could point the retrieval endpoint at that address and get the backend to fetch and return its content, turning a RAG ingestion feature into an SSRF pivot into cloud infrastructure. There's no public exploit, no Nuclei template, and it isn't in CISA KEV, so this looks opportunistic rather than actively weaponized today — but the attack complexity (AC:H) mainly reflects that it only bites Azure-hosted instances, not that it's hard to execute once you know the target IP. With 168 other CVEs already recorded against this package and 3 downstream dependents, prioritize confirming your exposure. Patch to Open WebUI 0.11.1 or later, and if you're on Azure, verify no unexpected outbound requests to 168.63.129.16 have occurred via retrieval logs.

Is CVE-2026-87999 actively exploited?

No confirmed active exploitation of CVE-2026-87999 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-87999?

Upgrade to Open WebUI 0.11.1 or later immediately — this is the only complete fix. Until patched, restrict egress from the Open WebUI host/container at the network layer (NSG/firewall) to block outbound access to 168.63.129.16 and other Azure platform-reserved ranges. If the web retrieval/search feature isn't business-critical, disable it for non-admin roles as a compensating control. Review retrieval request logs for `process/web` and `process/web/search` calls targeting internal or reserved IPs as a detection signal, and treat any hit as a confirmed exploitation attempt given there's no legitimate reason a user query would target that address.

What systems are affected by CVE-2026-87999?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, web retrieval / ingestion, self-hosted LLM UI, cloud-hosted inference deployments.

What is the CVSS score for CVE-2026-87999?

CVE-2026-87999 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.22%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesweb retrieval / ingestionself-hosted LLM UIcloud-hosted inference deployments

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.11.1, POST /api/v1/retrieval/process/web and POST /api/v1/retrieval/process/web/search in backend/open_webui/retrieval/web/utils.py treated Python's globally routable address classification as proof that a destination was external. An authenticated user could make an Azure-hosted instance fetch and return content from 168.63.129.16, the Azure platform channel, as well as other reserved ranges that the standard classification did not reject. This issue is fixed in version 0.11.1.

Exploitation Scenario

An attacker who has (or obtains via low-effort credential access) a standard, non-admin Open WebUI account issues a request to `POST /api/v1/retrieval/process/web` with a target URL of `http://168.63.129.16/...` instead of a normal web page. Because the backend's SSRF guard only rejects addresses classified as non-globally-routable — and 168.63.129.16, despite being a special-use Azure platform address, doesn't trip that check — the server-side fetch proceeds. The Azure-hosted Open WebUI instance retrieves whatever the platform channel returns and hands it back to the attacker through the normal chat/retrieval response, giving them visibility into data never intended to cross the tenant boundary, with no exploit tooling required beyond crafting the request.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.