PT-2026-89453 · Git+2 · Open-Webui

CVE-2026-88005

·

Published

2026-09-10

·

Updated

2026-09-10

CVSS v3.1

6.5

Medium

VectorAV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

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

Exploit

Fix

Incorrect Authorization

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-863

Related Identifiers

CVE-2026-88005
GHSA-4QG5-CXX4-G927

Affected Products

Open-Webui