CVE-2026-59218: Open WebUI: Account enumeration via observable login timing discrepancy

The signin handler looks the user up by email and runs the bcrypt comparison only if a record exists. A missing email returns early with no hashing. Every failed attempt returns HTTP 400, but the timing differs. In the reporter's run, a valid account took 186 ms and three unknown addresses took 9, 6 and 5 ms.

The built-in brute-force throttling does not stop this. One request at a time with a short pause stays under the rate limit and still shows the gap.

The attacker needs only network access to the login endpoint and a list of candidate emails. They learn which addresses are registered. No data is read or changed. The practical use is targeted password spraying against confirmed accounts, a risk the advisory says is higher because MFA is off by default. The score is 5.3 with confidentiality limited to account existence.

The open-webui pip package, all versions before 0.10.0. Any instance with password signin reachable by an attacker is affected, and exposure is greatest for internet-facing servers.

pip show open-webui

For Docker, check the image tag. To test an instance, time failed signin requests for a known account and a made-up address. A consistent gap of over 100 ms shows the flaw.

Upgrade to open-webui 0.10.0.

pip install --upgrade open-webui==0.10.0

The fix is pull request 26385. When the email does not resolve to an active credential, the authentication path now runs bcrypt against a constant placeholder hash. A real hash comparison happens on every attempt, so response time no longer depends on whether the account exists. The advisory lists no workaround. Turning on MFA and stronger rate limits at a reverse proxy lowers the risk from password spraying.

Look in access logs for many POST /api/v1/auths/signin requests returning HTTP 400, from one source or spread across sources, with a different email each time and a slow, steady pace. A stream of distinct, unrelated email addresses is typical of enumeration. Watch for later password spraying against the same accounts.

Summary

The /api/v1/auths/signin endpoint leaked whether an email address belonged to a registered account through a response-time side channel. Password verification ran bcrypt only when the email was found in the database; for a non-existent email the request returned early without hashing. The expensive bcrypt comparison therefore made valid-account attempts respond significantly slower (~180 ms) than non-existent ones (~5 ms), so an unauthenticated attacker could enumerate valid accounts by measuring response time.

Details

On signin the backend looked the user up by email and only performed the bcrypt password comparison if a record existed. A missing email short-circuited before any hashing, producing the timing gap. The built-in brute-force throttling did not prevent it: sending one request at a time with a small delay between requests stays under the rate limit while still exposing the difference.

Observed in the reporter's run (HTTP 400 for every attempt, the response time is the signal):

Email                Status   Response time
[email protected]      400      186 ms   <- valid account
[email protected]    400        9 ms
[email protected]     400        6 ms
[email protected]    400        5 ms

Impact

An unauthenticated attacker can enumerate which email addresses are registered accounts, which enables targeted password-spraying against confirmed accounts. The impact is amplified by MFA not being enabled by default. No data is read or modified; the disclosure is limited to account existence.

Patched

The authentication path now runs a bcrypt verification against a constant placeholder hash whenever the email does not resolve to an active credential, so a real hash comparison executes on every attempt and the response time is the same whether or not the account exists. Fixed in 0.10.0.

Credits

@dievus