Open WebUI CVE-2026-45675

Fresh Open WebUI deployment with LDAP authentication enabled (LDAP_URI and related environment variables configured) OR OAuth authentication enabled (OAUTH_PROVIDERS configured with at least one provider such as Google, Microsoft, GitHub). The instance must have zero existing user accounts in the database - exploitation is impossible if any user (admin or non-admin) already exists. DATABASE_ENABLE_SESSION_SHARING must be False (the default per env.py:387), which ensures each authentication request uses an isolated database session, widening the race window. Attacker must be able to authenticate via the configured LDAP server or OAuth provider (requires valid corporate credentials or OAuth tokens, not anonymous access). Multiple concurrent authentication requests must arrive within the race window, typically hundreds of milliseconds to a few seconds depending on database performance and network latency. Non-default configurations that LIMIT exploitation: DATABASE_ENABLE_SESSION_SHARING=True narrows the race window by sharing transaction context. Deployments using only the standard signup handler (no LDAP/OAuth) are not affected by this specific vulnerability. Single-user or staggered onboarding processes that create the first admin account before enabling LDAP/OAuth effectively close the window.

Real-world risk is constrained by narrow exploitation window but severe in impact when conditions align. CVSS 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) accurately reflects this trade-off: network-accessible unauthenticated attack but high complexity due to precise timing requirements. The AC:H (high attack complexity) rating is justified - exploitation requires concurrent requests during the brief first-deployment phase before any legitimate admin account exists, a window measured in seconds to minutes for typical deployments. No EPSS score or CISA KEV status indicates this has not been observed in widespread automated exploitation campaigns. However, GitHub advisory explicitly confirms public exploit code exists (POC=YES), lowering the skill barrier. SSVC framework assessment: Exploitation=POC (proof-of-concept public), Automatable=No (requires timing precision and deployment-specific knowledge of LDAP/OAuth configuration), Technical Impact=Total (full admin privileges grant access to all user data, API keys, LLM backend configurations, and system settings). Priority depends heavily on deployment context: organizations performing fresh Open WebUI rollouts with LDAP/OAuth in the next 30-90 days face genuine risk; existing deployments with established admin accounts cannot be exploited through this vector. The vulnerability's self-limiting nature (only exploitable on fresh instances) explains the absence of KEV listing despite high CVSS score.

An attacker monitors organizational communications or deployment schedules to identify when a new Open WebUI instance with LDAP or OAuth authentication will be launched. During the initial rollout window (typically first 15-60 minutes after deployment goes live), the attacker and one or more accomplices send precisely timed concurrent authentication requests through the LDAP or OAuth flow - for example, three users authenticate via corporate OAuth within a 500-millisecond window. All three requests execute the has_users() or get_num_users() check simultaneously while the database is still empty, each receiving a 'user count zero' response. All three user creation operations then proceed with role='admin' assignments. The attacker now possesses a persistent administrator account granting full access to all user conversations, API keys for connected LLM backends (OpenAI, Anthropic, local models), system configuration including authentication settings, and the ability to exfiltrate or manipulate data from all other users. GitHub advisory GHSA-h3ww-q6xx-w7x3 confirms public proof-of-concept code exists to demonstrate this timing attack.