CVE-2026-87996 in Open WebUI
Summary
by MITRE • 09/09/2026
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 until 0.11.1, SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py validated a user-controlled hostname in Python and then let the Playwright browser resolve it again in the sync and async request interceptors. An authenticated user controlling authoritative DNS could return a public address to validation and an internal address to the browser, exposing responses from internal services or cloud metadata through web search or URL ingestion. This issue is fixed in version 0.11.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within Open WebUI versions ranging from 0.9.6 to 0.11.1 represents a critical server-side request forgery flaw rooted in flawed hostname validation logic during web retrieval operations. The core technical deficiency lies in the implementation of the SafePlaywrightURLLoader component, specifically located in the backend/open_webui/retrieval/web/utils.py module. This component is responsible for processing user-supplied URLs to fetch content via an automated browser instance powered by Playwright. While the system attempts to mitigate risks associated with SSRF attacks by validating the hostname provided by the user against a list of allowed or safe domains, this validation step operates independently from the actual network resolution performed later in the request lifecycle. The architecture relies on Python's standard library functions for initial hostname verification but delegates the final DNS resolution and connection establishment to Playwright’s browser engine through both synchronous and asynchronous request interceptors. This separation creates a significant security gap because the validation check does not account for dynamic changes that can occur between the time of validation and the actual network transaction, particularly when external factors influence domain name system responses.
An attacker with authenticated access to the Open WebUI platform can exploit this race condition or logic bypass by leveraging control over authoritative DNS records associated with a permitted hostname. By manipulating these DNS records, an adversary can cause the initial Python-based validation step to resolve and verify against a public IP address that is deemed safe or allowed by the application’s policy. However, when Playwright subsequently attempts to establish the actual connection using its own browser context, it performs a fresh DNS lookup at that later moment. If the attacker has updated their authoritative DNS records in the interim, this second resolution can return an internal private IP address, such as those found in RFC 1918 ranges or cloud metadata endpoints like AWS EC2 instance metadata service addresses. Consequently, the browser proceeds to make a request to what appears to be a safe domain during validation but actually targets sensitive internal infrastructure services that are typically inaccessible from external networks due to network segmentation and firewall rules.
The operational impact of this vulnerability is severe, as it effectively bypasses server-side protections designed to prevent unauthorized access to internal resources. Through the web search functionality or direct URL ingestion features, an authenticated user can force the application to fetch data from internal services that are not intended for public exposure. This includes sensitive cloud metadata endpoints which often contain authentication tokens, IAM credentials, and configuration details essential for maintaining the integrity of cloud environments. Additionally, requests may be directed toward internal databases, administrative interfaces, or other microservices running on private networks within the same infrastructure. The ability to exfiltrate data from these internal services compromises confidentiality and potentially allows further lateral movement within the network if combined with other vulnerabilities. This behavior aligns closely with Common Weakness Enumeration CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side code makes requests based on user input without proper validation of the resolved IP address or hostname at the time of execution.
From a threat intelligence perspective, this vulnerability maps to MITRE ATT&CK technique T1502.003, known as Service Staging: Cloud Infrastructure Discovery, specifically when used for lateral movement and data exfiltration from cloud metadata services. It also relates to T1498 Network Denial of Service if the attacker uses the internal service requests to trigger resource exhaustion or disrupt operations indirectly through excessive querying. The exploitation requires authenticated access, which limits the attack surface to compromised accounts or insider threats but significantly increases the potential damage due to the elevated privileges typically associated with such users in enterprise deployments. To mitigate this risk, organizations must ensure they are running Open WebUI version 0.11.1 or later where the validation logic has been corrected to prevent DNS rebinding attacks by ensuring consistent resolution between validation and execution phases. In environments where upgrading is not immediately feasible, network-level controls such as egress filtering should be implemented to block outbound connections from application servers to private IP ranges and cloud metadata endpoints. Additionally, implementing strict allowlists for both validated hostnames and their corresponding resolved IPs at runtime can provide an additional layer of defense against this class of SSRF vulnerabilities.