mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-08 21:09:41 -05:00
[PR #21631] [MERGED] fix: race condition in signup allows multiple admin accounts #65027
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/21631
Author: @theeggorchicken
Created: 2/20/2026
Status: ✅ Merged
Merged: 2/21/2026
Merged by: @tjbck
Base:
dev← Head:fix/signup-race-condition📝 Commits (1)
c86a69ffix: race condition in signup allows multiple admin accounts📊 Changes
1 file changed (+11 additions, -7 deletions)
View changed files
📝
backend/open_webui/routers/auths.py(+11 -7)📄 Description
Pull Request Checklist
devbranch.fix:Changelog Entry
Description
Race condition in
signup_handlerallows multiple admin account registrations on fresh deployments when running with multiple uvicorn workers.Fixed
signup_handlerwherehas_users()check is not atomic withinsert_new_auth(). With multiple workers, concurrent signup requests during first-user registration can all see an empty user table and each receive the admin role.Security
Vulnerable Lines
File:
backend/open_webui/routers/auths.py#L703-L709What could happen
On a fresh Open WebUI deployment with multiple uvicorn workers (
--workers >= 2), an attacker can send concurrent signup requests during first-user registration. Each worker'shas_users()returns False before any insert completes, so multiple accounts get the admin role. I tested with 4 workers and 30 concurrent requests — 4 accounts got admin, each with full admin privileges (listing users, reading config, managing the instance).How to verify
UVICORN_WORKERS=4andENABLE_SIGNUP=true/api/v1/auths/signupwith different email addresses"role": "admin"— without this fix, multiple willWhat this PR does
Reverses the signup flow: insert the user with the default role first, then atomically check if the user count is 1 (meaning this is the only user). Only then promote to admin. This closes the race window because after the insert, the count includes the just-inserted row — if two workers insert concurrently, both will see count >= 2 and neither gets promoted.
Evidence
Full race condition exploit traces: https://gist.github.com/theeggorchicken/455f6c46ea73bd96396400a679c3c207
Contributor License Agreement
By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.