CVE-2026-109293 in Open WebUI
Summary
by MITRE • 10/12/2026
Open WebUI from 0.11.0 before 0.11.4 contains an information disclosure vulnerability that allows authenticated non-admin users with tool export permission to obtain tool source code shared with them read-only. Attackers can request GET /api/v1/tools/export to retrieve the full Python source of read-only shared tools, exposing embedded API keys and credentials.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The Open WebUI platform, specifically versions ranging from 0.11.0 up to but not including 0.11.4, contains a critical information disclosure vulnerability that stems from insufficient access control mechanisms within its tool export functionality. This flaw allows authenticated users who possess the permission to export tools to retrieve sensitive source code artifacts that they should only have read-only access to in their operational context. The core technical issue lies in the API endpoint GET /api/v1/tools/export, which fails to properly distinguish between permissions granted for functional usage of a tool and permissions granted for inspecting or exporting its underlying implementation details. Consequently, any user with the export permission can invoke this endpoint against tools that are shared with them on a read-only basis, thereby bypassing the intended restrictions designed to protect intellectual property and sensitive configuration data embedded within those tools.
From a technical perspective, the vulnerability exploits the lack of granular authorization checks when processing requests for tool exports. While the user interface may restrict direct editing or full administrative control over shared tools, the backend API endpoint does not validate whether the requesting user is authorized to view the source code itself. This architectural oversight results in the server returning the complete Python source code of the requested tool. Since these tools often contain hardcoded credentials, such as API keys for external services like language models or database connections, this exposure poses a severe security risk. The attacker does not need elevated privileges beyond basic export rights to extract this sensitive data, making it relatively easy to exploit even by lower-privileged users within an organization's Open WebUI instance.
The operational impact of this vulnerability is significant, primarily due to the nature of the exposed data. API keys and credentials embedded in tool source code are often used for authentication with third-party services or internal systems. If these secrets are compromised, attackers can impersonate legitimate services, access unauthorized data stores, or incur financial costs by abusing cloud service quotas associated with those keys. Furthermore, exposing proprietary algorithm logic or custom integration scripts may reveal business-critical intellectual property to competitors or malicious actors within the same network environment. This breach of confidentiality undermines trust in the platform's ability to isolate multi-tenant workloads and protect shared resources from unauthorized inspection.
This vulnerability aligns with CWE-200, which classifies Information Exposure as a category where sensitive information is disclosed without proper access controls. It also maps to MITRE ATT&CK technique T1530, Data from Cloud Storage Object or Service, specifically in the context of accessing data that was not intended for public or broad internal consumption. To mitigate this risk, organizations should immediately upgrade Open WebUI to version 0.11.4 or later, where these access control checks have been corrected. In environments where upgrading is not immediately feasible, administrators can restrict export permissions to only those users who genuinely require them and audit existing tool configurations for hardcoded secrets. Additionally, implementing a secret scanning process in CI/CD pipelines can help detect embedded credentials before they are deployed into production tools, reducing the blast radius if such vulnerabilities persist or reappear in future versions.