CVE-2026-88006: Open WebUI: Users denied by the OAuth role policy can still sign in via token exchange

The token exchange endpoint in backend/open_webui/routers/auths.py looks up the account for a provider access token and issues a session. It was added as a second way into the path the login callback uses, and it re-implemented only the identity lookup. Role evaluation sat inside the callback's own body, so the endpoint never ran it.

An administrator who relies on OAuth role management expects a user to lose access, or lose admin, once the identity provider stops reporting the required role. The callback does that at the next sign-in. Token exchange never re-evaluated the role. A user presenting a valid provider token kept a session at their existing role, including an admin role that had already been revoked at the provider.

The endpoint cannot create accounts and cannot raise a role, so the flaw gives continued access, not new access. For an off-boarded admin that continued access is still serious.

Three settings must line up. ENABLE_OAUTH_TOKEN_EXCHANGE must be true (off by default). ENABLE_OAUTH_ROLE_MANAGEMENT must be true with OAUTH_ALLOWED_ROLES or OAUTH_ADMIN_ROLES set (also off by default). The user needs a valid, unexpired token and an account already linked to the provider subject, or one matched by email when OAUTH_MERGE_ACCOUNTS_BY_EMAIL is on.

Affected: open-webui from 0.8.0 up to but not including 0.11.1, with ENABLE_OAUTH_TOKEN_EXCHANGE=True, ENABLE_OAUTH_ROLE_MANAGEMENT=True and OAUTH_ALLOWED_ROLES or OAUTH_ADMIN_ROLES set. Default deployments are not affected. Check the version:

pip show open-webui

Then check the three settings in your deployment's environment.

Upgrade to 0.11.1:

pip install --upgrade open-webui==0.11.1

The fix (commit d799e81e) makes token_exchange call the new update_user_from_oauth method, the same role evaluation the callback uses. It also runs group mapping when that is enabled. The exchange now returns 403 when the provider's roles match no allowed or admin role, and the account's role is updated to match the provider otherwise. No further action is needed. The sources give no workaround. Turning off ENABLE_OAUTH_TOKEN_EXCHANGE removes the exposure if you do not use that endpoint, which follows from the preconditions.

List users whose provider roles no longer match OAUTH_ALLOWED_ROLES or OAUTH_ADMIN_ROLES but who still hold sessions or an elevated role in Open WebUI. Check access logs for calls to the OAuth token exchange endpoint from those accounts. On a fixed version such a call returns 403. The advisory gives no log line.

Summary

Open WebUI's OAuth token exchange endpoint issues a session for a provider access token without running the OAuth role management that the normal OAuth login callback runs. A user whose provider roles the login callback would refuse, or would demote, could still obtain a working session at their existing role through this endpoint.

Preconditions

• ENABLE_OAUTH_TOKEN_EXCHANGE=True. It is disabled by default, so a default deployment is not affected.
• ENABLE_OAUTH_ROLE_MANAGEMENT=True together with OAUTH_ALLOWED_ROLES or OAUTH_ADMIN_ROLES. Role management is off by default, and deployments not using it 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 relies on OAuth role management expects a user to lose access, or lose admin, as soon as the identity provider stops reporting the required role. The login callback does enforce this on the next sign-in. Token exchange kept issuing sessions and never re-evaluated the role, so the user retained working access as their existing account at its existing role, including an admin role the provider had already revoked. The endpoint cannot create an account and cannot raise anyone's role, so this grants continued access rather than new or elevated access.

Fix

d799e81ed, released in 0.11.1, runs the same role evaluation on the provider's response that the login callback runs. The exchange is denied with 403 when the reported roles match no allowed or admin role, and the account's role is updated to match the provider otherwise. 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. Role evaluation lived inside the callback's own body rather than in shared code, so the second caller inherited none of it.

Credits

@Classic298