GHSA-4qg5-cxx4-g927 is a medium-severity (CVSS 6.5) CWE-863 vulnerability in open-webui. O3 Security confirms whether GHSA-4qg5-cxx4-g927 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Open WebUI: Users denied by the OAuth domain allowlist or role policy can still sign in via token exchange
Real-World Exposure
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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_DOMAINSset 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_EMAILis 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | ≥ 0.8.0&&< 0.9.0 | 0.9.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update open-webui to 0.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4qg5-cxx4-g927 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-4qg5-cxx4-g927 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4qg5-cxx4-g927. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4qg5-cxx4-g927 in your dependencies?
O3 detects GHSA-4qg5-cxx4-g927 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.