CVE-2026-88005 in Open WebUI
Summary
by MITRE • 09/10/2026
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.8.0 until 0.9.0, Open WebUI's OAuth token exchange endpoint issues a session for a provider access token without applying the email domain allowlist that the normal OAuth login callback enforces. An account whose email domain the login callback would refuse could still obtain a working session through this endpoint. This issue is fixed in version 0.9.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified within Open WebUI versions ranging from 0.8.0 to 0.9.0 represents a critical authentication bypass mechanism rooted in inconsistent security policy enforcement across different endpoints of the OAuth integration flow. As an extensible and self-hosted AI platform, Open WebUI relies heavily on external identity providers for user management and access control. A core component of this security model is the email domain allowlist, which serves as a restrictive measure to ensure that only users from approved organizational domains can authenticate and gain access to the system. This restriction is typically enforced during the standard OAuth login callback process, where the application validates the incoming identity information against its configured whitelist before establishing a user session.
The technical flaw lies in the implementation of the token exchange endpoint, which handles the conversion of provider-specific access tokens into internal Open WebUI sessions. While the primary authentication flow correctly applies the domain allowlist logic to filter out unauthorized email domains, this specific security control was omitted from the token exchange routine. Consequently, an attacker who possesses a valid access token from an external identity provider can interact directly with this endpoint to request a session cookie or JWT without triggering the domain validation checks that are present in the standard login callback. This discrepancy creates a logic flaw where the application trusts the validity of the external token but fails to verify if the user associated with that token is permitted to access the internal system based on their email domain.
From an operational perspective, this vulnerability allows for unauthorized account creation and session establishment by individuals whose email domains are explicitly blocked by the organization's security policies. An attacker could potentially create a new administrative or standard user account in Open WebUI simply by obtaining a valid OAuth token from any provider that supports such flows, regardless of whether their domain is whitelisted. This undermines the principle of least privilege and can lead to data leakage within the AI platform, especially if sensitive documents are processed through the self-hosted instance. The impact is particularly severe in enterprise environments where Open WebUI might be integrated with corporate identity providers like Azure AD or Okta, as it allows external entities to bypass domain-based access controls entirely.
This issue aligns with CWE-284, which describes Improper Access Control, specifically highlighting the failure to enforce restrictions on authenticated users based on their privileges and roles. Furthermore, in the context of the MITRE ATT&CK framework, this vulnerability facilitates Initial Access through exploitation of authentication bypass techniques, allowing adversaries to establish a foothold within the system without valid credentials for an allowed domain. The root cause is essentially a lack of consistent security validation across all entry points that result in session creation, demonstrating how partial implementation of security controls can lead to significant breaches even when other parts of the application are secure.
To mitigate this vulnerability, organizations running Open WebUI must immediately upgrade to version 0.9.0 or later, where the token exchange endpoint has been patched to enforce the same email domain allowlist checks as the standard login callback. For environments that cannot yet update due to dependency constraints, temporary mitigations should include restricting network access to the OAuth endpoints if possible and closely monitoring for new user account creations from unexpected domains. Additionally, implementing strict logging and alerting on authentication events can help detect attempts to exploit this bypass before significant damage occurs. Regular audits of identity provider configurations and application code reviews are recommended to ensure that all authentication paths consistently apply organizational security policies without exception.