CVE-2026-54019: Open WebUI Milvus Multitenancy ACL Bypass – CVSS 6.5

Technical summary

The vulnerability stems from an authorization bypass in Open WebUI's collection-level access control logic. When Milvus multitenancy mode is enabled, user-controlled collection names are accepted as valid identifiers for legacy or ephemeral collections without proper validation. These names are then interpolated directly into Milvus query expressions without proper escaping or parameterization. An authenticated attacker can craft malicious collection names containing special characters or expressions that break out of the intended query context, allowing them to access collections outside their assigned scope. The root cause is that the ACL implementation treats unknown collection names as implicitly allowed legacy collections, and the subsequent use of these names in database queries lacks input sanitization. The issue represents an incomplete remediation of CVE-2026-44560, suggesting the original fix did not fully address the underlying design flaw.

Business impact

For organizations using Open WebUI to manage AI models and datasets, this vulnerability poses a confidentiality risk. An insider or compromised account holder can read sensitive information from collections they are not authorized to access—including training datasets, proprietary model outputs, or user interaction logs. This could lead to data exfiltration, intellectual property theft, or compliance violations depending on what data is stored in Open WebUI. The impact is limited to authenticated users, reducing but not eliminating risk in shared or multi-tenant environments. Organizations relying on Open WebUI for regulated AI workloads should treat this as a moderate priority issue requiring prompt patching.

Affected systems

Open WebUI versions prior to 0.9.6 are affected when running in Milvus multitenancy mode. Organizations using Open WebUI without Milvus multitenancy, or with a standard single-tenant Milvus deployment, face lower risk but should still upgrade. The vulnerability does not affect offline-only deployments that do not use the Milvus vector database or that run Milvus in non-multitenancy mode. Verify your deployment architecture: check whether Milvus is enabled, whether multitenancy mode is active, and which Open WebUI version is deployed.

Exploitability

The attack requires valid user credentials and network access to the Open WebUI instance. No special user privileges are needed—a standard authenticated user can exploit this. The attack is straightforward to execute: an attacker simply submits requests with crafted collection names that include SQL or expression injection payloads. The attack is likely to succeed reliably against affected versions in Milvus multitenancy mode because input validation is absent. However, the barrier to entry is authentication, which limits opportunistic attacks from the internet. This is classified as a medium-severity issue because it requires prior account access and does not permit privilege escalation or code execution.

Remediation

Upgrade Open WebUI to version 0.9.6 or later. This release includes corrected collection-level ACL enforcement and proper input escaping for collection names in Milvus queries. Verify the upgrade completes successfully and that Milvus multitenancy mode is still operational. For organizations unable to patch immediately, consider disabling Milvus multitenancy mode if your deployment allows it, or restricting network access to Open WebUI to trusted internal networks only. Audit recent collection access logs for suspicious queries or unauthorized data reads.

Patch guidance

Deploy Open WebUI 0.9.6 as soon as operationally feasible. The patch directly addresses the authorization bypass by implementing proper input validation and query parameterization. Test the upgrade in a staging environment first to confirm compatibility with your Milvus configuration and existing collections. No special migration steps are required. After upgrading, verify that collection-level permissions are enforced correctly by testing access from user accounts with restricted permissions. Monitor application logs during and after the upgrade for any query errors that might indicate misconfiguration.

Detection guidance

Search application logs and Milvus query logs for patterns indicating exploitation: multiple requests containing special characters (quotes, parentheses, operators) in collection name parameters, particularly from a single user account. Look for error messages from Milvus indicating malformed expressions or out-of-scope collection access. Network monitoring can flag unusual API calls to collection endpoints from internal users. If Open WebUI audit logs are available, examine ACL bypass events or permission check failures. Forensic analysis should focus on identifying which collections were accessed and by which users, especially if those accesses violated configured policies.

Why prioritize this

This vulnerability merits prompt but not emergency patching. It requires authentication, limits exposure to data confidentiality, and does not enable code execution or lateral movement. However, organizations running Milvus in multitenancy mode to enforce data isolation between tenants should treat this as higher priority because the vulnerability directly undermines the security model they rely on. Insider threat scenarios and environments with high-sensitivity training data should prioritize the patch. Standard deployments without multitenancy can schedule the upgrade within a normal maintenance window but should not delay excessively.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects a network-accessible, low-complexity attack requiring valid user credentials, resulting in high confidentiality impact but no integrity or availability loss. The score appropriately captures that this is a read-only authorization bypass affecting sensitive data. The attack vector (network), access complexity (low), and privileges required (low user-level) are correct. The severity could be higher in specific contexts where collections contain highly sensitive information, but the generic score is reasonable. Organizations should consider context-specific risk elevation if their threat model includes malicious insiders or if their data classification requires stronger access controls.

Frequently asked questions