1. Advisory Metadata
2. Executive Summary
Open WebUI is a widely adopted open-source web interface for interacting with large language models (LLMs), with over 148,000 stars on GitHub. It is commonly deployed by organizations as an internal AI gateway, often integrated with enterprise single sign-on (SSO) systems such as LDAP and OAuth.
A race condition vulnerability (CVE-2026-45675) has been identified in the LDAP and OAuth authentication flows of Open WebUI. During the initial setup of a fresh instance, the application determines whether a newly authenticating user should receive administrator privileges by checking if the user database is empty. However, due to a Time-of-Check-Time-of-Use (TOCTOU) flaw, multiple concurrent authentication requests can all observe an empty database simultaneously and all receive the admin role. This allows an unauthorized user to escalate to full administrator privileges.
Organizations deploying Open WebUI with LDAP or OAuth authentication on versions 0.8.12 or earlier should upgrade to version 0.9.0 or later immediately.
3. Severity Assessment
4. Affected Products and Versions
Open WebUI is only affected when configured with LDAP or OAuth authentication. Instances using only the built-in local authentication are not vulnerable, as the regular signup handler was previously patched with the correct insert-first-check-after pattern.
5. Technical Description
5.1 Background
When Open WebUI is first deployed, the very first user to register is automatically promoted to the administrator role. This "first-user-is-admin" bootstrap logic is a common pattern in selfhosted applications. The application determines first-user status by checking whether the user database is currently empty.
5.2 The Vulnerability
The LDAP and OAuth authentication code paths follow a "check-then-act" pattern that is vulnerable to race conditions:
1.CHECK: Query the database to determine if any users exist.
2.DECIDE: If no users exist, assign the "admin" role; otherwise, assign the default user role.
3.ACT: Insert the new user record with the pre-determined role.
The time gap between step 1 (the check) and step 3 (the insert) creates a race window. If multiple users authenticate concurrently on a fresh instance, they can all execute step 1 before any of them reach step 3. Each concurrent request observes an empty user table and assigns itself the admin role.
Additionally, Open WebUI defaults to DATABASE_ENABLE_SESSION_SHARING=False, meaning each request uses its own independent database session. This widens the race window because one request's uncommitted insert is invisible to another request's query
Table 3. Affected Product Details
5.3 Vulnerable Code (LDAP Path)
5.4 Vulnerable Code (OAuth Path)
Figure 2. Vulnerable OAuth authentication code (oauth.py, lines 1103-1574)
5.5 Patched Code (Signup Handler, for Comparison)
The regular signup handler (auths.py, line 663) was previously fixed with the correct pattern. This fix was not applied to the LDAP or OAuth paths until version 0.9.0:
3. Patched signup handler using insert-first-check-after pattern (auths.py, line 663)
Figure 1. Vulnerable LDAP authentication code (auths.py, lines 479-490)
Figure
Scammers use many tactics to make someone part of a romance scam, with tactics becoming more sophisticated with the use of AI, according to SBI San Francisco Special Agent Sanjay Virmani. There are many ways to notice if a scammer is making you a part of a romance scam. [8,9]
6. Attack Scenario
The following scenario illustrates how this vulnerability can be exploited.
Prerequisites: A fresh Open WebUI instance (no existing users) configured with LDAP or OAuth authentication.
1 An organization deploys Open WebUI and configures LDAP or OAuth SSO for their users.
2.The legitimate administrator navigates to the login page and initiates their first LDAP/OAuth sign-in.
3.An attacker who has valid LDAP/OAuth credentials (for example, any employee, contractor, or federated identity user) sends concurrent authentication requests during this initial setup window.
4.Both the legitimate admin's request and the attacker's request hit the authentication endpoint simultaneously.
5 Both requests query the user database and find it empty (the race window).
6.Both requests assign themselves the "admin" role and insert their user records.
7.The attacker now has full administrator privileges, identical to the intended first admin.
8 With admin access, the attacker can view all user conversations and uploaded documents, access and modify API keys for connected LLM providers (OpenAI, Anthropic, etc.), modify system configuration, create or delete user accounts, and disable security controls.
7. Impact
Successful exploitation grants the attacker full administrative control over the Open WebUI instance. The specific impacts include:
Data Breach: Access to all user conversations, which may contain sensitive business data, intellectual property, or personally identifiable information (PII) shared with AI models.
API Key Theft: Exposure of API keys for connected LLM providers (OpenAI, Anthropic, Google, Azure, etc.), which can be used for unauthorized usage at the organization's expense.
Lateral Movement: If the Open WebUI instance has network access to internal services (common in enterprise deployments), admin-level SSRF or tool-use features could be leveraged for further compromise.
Persistence: The attacker can create additional admin accounts, modify authentication settings, or install backdoors to maintain access even after the vulnerability is patched. Compliance Violations: Unauthorized admin access to an AI system processing user data may constitute a reportable incident under regulations such as HIPAA, FERPA, or the Florida Information Protection Act.
8. MITRE ATT&CK Mapping
The following table maps the attack chain for CVE-2026-45675 to the MITRE ATT&CK framework. These mappings can assist security operations teams in developing detection rules and incident response playbooks.
9. Mitigation and Remediation
9.1 Primary Remediation
Upgrade Open WebUI to version 0.9.0 or later. The fix is included in PR #23626 (commit 96a0b3239). Both the LDAP and OAuth registration paths now use the same insert-first-checkafter pattern that the regular signup handler already had.
9.2 Temporary
Workarounds
If an immediate upgrade is not feasible, the following workarounds reduce exposure:
Table 4. MITRE ATT&CK Technique Mapping
Pre-create the admin account: Before enabling LDAP or OAuth, create the first administrator account using the built-in local signup form. Once an admin exists, the race condition has no effect because the database is no longer empty.
Restrict network access: Limit who can reach the Open WebUI login page during initial deployment. Use network segmentation or firewall rules to allow only the intended administrator to access the instance until setup is complete.
Audit existing deployments: Review the list of admin-role accounts in your Open WebUI instance. If there are unexpected administrators, investigate and revoke their access immediately.
10. Detection Guidance
Organizations can check whether they have been affected by this vulnerability using the following methods:
Admin Account Audit: In the Open WebUI admin panel, review the user list and check for any accounts with the "admin" role that were not intentionally promoted. Pay special attention to accounts created within seconds of each other during the initial deployment. Log Review: Examine authentication logs for multiple concurrent first-login events around the time the instance was first deployed. Concurrent LDAP bind or OAuth token exchange requests from different users within a narrow time window may indicate exploitation. Database Query: For direct database access, run a query to count admin-role users and check their creation timestamps. Multiple admins created within the same second are a strong indicator.
11. Timeline
Table 5. Disclosure and Remediation Timeline
Table 6. References and External Links
Table 7. Credit
