CVE-2026-88005: Open WebUI: OAuth token exchange bypasses domain allowlist

## 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

A vendor organization enables `ENABLE_OAUTH_TOKEN_EXCHANGE` to support a mobile or CLI client that authenticates via provider tokens, and restricts `OAUTH_ALLOWED_DOMAINS` to its own corporate domain. A contractor with an external email domain had a linked Open WebUI account from an earlier partnership. When the partnership ends, the admin removes the contractor's domain from the allowlist, expecting their next login to be denied — and it is, via the standard callback. However, the contractor (or malware holding their still-valid provider access token) calls the token-exchange endpoint directly instead of the login UI; because that endpoint never re-checks the allowlist, it issues a session anyway, letting the contractor continue querying the organization's internal LLM chat environment, connected knowledge bases, or agent tools at their prior role — undetected because no login-callback denial was ever logged.