CVE-2026-88005: Open WebUI: Users denied by the OAuth domain allowlist or role policy can still sign in via token exchange

The OAuth token exchange endpoint in backend/open_webui/routers/auths.py was added as a second way into the session-issuing path used by the login callback. It re-implemented the identity lookup but not the policy checks around it. The domain allowlist check lived inside the callback's own body, so the endpoint never ran it.

An administrator who narrows OAUTH_ALLOWED_DOMAINS expects users outside it to lose access at their next sign-in. The callback denies them. Token exchange kept issuing sessions. A user whose domain was removed can present a valid provider access token and get a session as their existing account, at its existing role.

The limits are real. The endpoint never creates accounts, so a token for a subject with no linked account is rejected. It cannot raise anyone's role. The result is continued access, not new or elevated access.

The preconditions are all required. ENABLE_OAUTH_TOKEN_EXCHANGE must be true (off by default). OAUTH_ALLOWED_DOMAINS must be set to something other than *. The user needs a valid, unexpired access token on the configured provider, plus an account already linked to that provider subject, or one matched by email when OAUTH_MERGE_ACCOUNTS_BY_EMAIL is on.

Affected: open-webui from 0.8.0 up to but not including 0.9.0, with ENABLE_OAUTH_TOKEN_EXCHANGE=True and OAUTH_ALLOWED_DOMAINS set to a value other than *. Default deployments, and those with no domain allowlist, are not affected. Check the version:

pip show open-webui

Then check both environment variables in your deployment.

Upgrade to 0.9.0:

pip install --upgrade open-webui==0.9.0

The fix (commit fb5ef978, pull request 23639) adds the same domain allowlist check to the token exchange endpoint that the login callback runs. It returns 403 when the email domain is not allowed. No further action is needed. The sources give no workaround. Setting ENABLE_OAUTH_TOKEN_EXCHANGE to false removes the exposure if you do not use that endpoint. The sources do not state this, but it follows from the precondition.

Review sign-in activity for accounts whose email domain is no longer in OAUTH_ALLOWED_DOMAINS but that still start sessions. Check access logs for calls to the OAuth token exchange endpoint from those accounts. After the fix, such calls return 403. The advisory gives no log line.

Summary

Open WebUI's OAuth token exchange endpoint issues a session for a provider access token without applying the email domain allowlist that the normal OAuth login callback enforces. An account whose email domain the login callback would refuse could still obtain a working session through this endpoint.

Preconditions

• ENABLE_OAUTH_TOKEN_EXCHANGE=True. It is disabled by default, so a default deployment is not affected.
• OAUTH_ALLOWED_DOMAINS set to something other than *. Deployments without a domain allowlist are not affected.
• A valid, unexpired access token on the configured provider.
• An Open WebUI account already linked to that provider subject, or an account with a matching email when OAUTH_MERGE_ACCOUNTS_BY_EMAIL is enabled. This endpoint never creates accounts, so a token for a subject with no existing account is rejected.

Impact

An admin who narrows the domain allowlist expects users outside it to lose access at their next sign-in. The login callback does deny them. Token exchange kept issuing sessions, so a user whose domain was removed retained working access as their existing account at its existing role. The endpoint cannot create an account and cannot raise anyone's role, so this grants continued access rather than new or elevated access.

Fix

fb5ef978b, released in 0.9.0, adds the same domain allowlist check to the token exchange endpoint that the login callback runs, and denies the exchange with 403 when the email domain is not allowed. Upgrading restores the check with no further action.

Root cause

The affected component is the OAuth token exchange endpoint in backend/open_webui/routers/auths.py, present in builds from 0.8.0 onward.

The endpoint was added as a second entry point into the same session-issuing path the OAuth login callback uses, but it re-implemented only the identity lookup and not the policy checks surrounding it. The domain allowlist check lived inside the callback's own body rather than in shared code, so the second caller inherited none of it.

Credits

@Classic298