GHSA-4qg5-cxx4-g927: Medium severity pip/open-webui vulnerability
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 - ENABLEOAUTHTOKENEXCHANGE=True. It is disabled by default, so a default deployment is not affected. - OAUTHALLOWEDDOMAINS 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 OAUTHMERGEACCOUNTSBYEMAIL 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/openwebui/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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/open-webuito a version that resolves this vulnerability.Fixed in 0.9.0 - Upgrade
Upgrade
Open WebUIto a version that resolves this vulnerability.Fixed in 0.9.0Patch fb5ef978b - Configuration
If you are not explicitly using OAuth token exchange, disable it by setting ENABLE_OAUTH_TOKEN_EXCHANGE=False; the issue affects the OAuth token exchange endpoint when ENABLE_OAUTH_TOKEN_EXCHANGE=True.
Open WebUI ENABLE_OAUTH_TOKEN_EXCHANGE = True
Event History
Frequently Asked Questions
Which deployments are affected?
Only deployments with ENABLE_OAUTH_TOKEN_EXCHANGE enabled and OAUTH_ALLOWED_DOMAINS configured to a value other than *. The token-exchange feature is disabled by default, and deployments without a domain allowlist are not affected.
What does an attacker need to obtain a session through the token-exchange endpoint?
They need a valid, unexpired access token from the configured OAuth provider. The provider subject must already be linked to an Open WebUI account, or its email must match an existing account when OAUTH_MERGE_ACCOUNTS_BY_EMAIL is enabled.
Can this endpoint be used to create a new Open WebUI account?
No. The endpoint does not create accounts, and rejects tokens for provider subjects that have no existing eligible account relationship.
What access does a bypassing user receive?
A user whose domain was removed from the allowlist can retain access through token exchange as their existing account, with that account's existing role. The normal OAuth login callback continues to deny that user.
What can be done if remediation cannot be applied immediately?
Disable ENABLE_OAUTH_TOKEN_EXCHANGE, or avoid using a restrictive OAUTH_ALLOWED_DOMAINS configuration until the issue is addressed. The affected condition requires both token exchange to be enabled and a domain allowlist other than *.