PT-2026-59372 · Pypi · Open-Webui

Published

2026-07-13

·

Updated

2026-07-13

CVSS v3.1

8.1

High

VectorAV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Summary

The LDAP and OAuth authentication flows use a TOCTOU (Time-of-Check-Time-of-Use) pattern for first-user admin role assignment. The regular signup handler (signup handler in auths.py, line 663) was explicitly patched to prevent this race with the comment "Insert with default role first to avoid TOCTOU race", but the LDAP and OAuth code paths were never updated with the same fix.

Vulnerable Code

LDAP (auths.py, lines 479-490)

python
# Line 482 - CHECK: is the user table empty?
role = 'admin' if not Users.has users(db=db) else request.app.state.config.DEFAULT USER ROLE

# Lines 484-490 - USE: create user with the role determined above
user = Auths.insert new auth(
  email=email,
  password=str(uuid.uuid4()),
  name=cn,
  role=role,  # <-- role was determined BEFORE insert, race window exists
  db=db,
)

OAuth (oauth.py, lines 1103-1112, 1566-1574)

python
# Line 1104 - CHECK: count users
def get user role(self, user, user data):
  user count = Users.get num users()
  if not user and user count == 0:
    return 'admin'  # Line 1112

# Lines 1566-1574 - USE: create user with pre-determined role
user = Auths.insert new auth(
  ...
  role=self.get user role(None, user data), # Line 1571
  ...
)
Both paths determine the role BEFORE inserting the user, creating a race window where multiple concurrent requests on a fresh instance can all observe an empty database and all receive the admin role.

Comparison with Patched Signup

The signup handler (auths.py, line 663) was explicitly fixed:
python
# Insert with default role first to avoid TOCTOU race
user = Auths.insert new auth(..., role=DEFAULT USER ROLE, ...)
# Then check if this is the only user and upgrade
if Users.get num users() == 1:
  Users.update user role by id(user.id, 'admin')
The LDAP and OAuth paths did NOT receive this fix.

Exploitation

  1. Deploy Open WebUI with LDAP or OAuth enabled on a fresh instance (no existing users)
  2. Send multiple concurrent authentication requests from different users
  3. Multiple requests pass the has users() / get num users() == 0 check simultaneously
  4. All concurrent users become administrators
DATABASE ENABLE SESSION SHARING defaults to False (env.py:387), so each call uses its own database session, widening the race window.

Impact

Any LDAP/OAuth user who times their first login concurrently with the legitimate first admin can escalate to full admin privileges, gaining access to all user data, system configuration, API keys, and connected LLM backends.

Suggested Fix

Apply the same insert-then-check pattern used in signup handler: insert the user with DEFAULT USER ROLE first, then atomically check if this is the only user and upgrade to admin only if so.

Resolution

Fixed in PR #23626 (commit 96a0b3239), first released in v0.9.0 (Apr 2026). Both LDAP (routers/auths.py) and OAuth (utils/oauth.py) registration paths now use the same insert-first-check-after pattern that signup handler already had:
  1. Insert the new user with DEFAULT USER ROLE unconditionally — no pre-insert role decision based on user count.
  2. After the insert commits, atomically call Users.get num users() == 1 to check whether this is the sole user.
  3. Only the sole user gets promoted to admin via Users.update user role by id.
OAuthManager.get user role was also updated to return DEFAULT USER ROLE (not admin) for first-user bootstrap; admin promotion is deferred to the post-insert check above. With this ordering, two concurrent first-user registrations that both observe an empty table can both insert, but only one will see get num users() == 1 afterward — the other will see == 2 and not be promoted.
Users on >= 0.9.0 are not affected.

Fix

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

PYSEC-2026-2730

Affected Products

Open-Webui