--- id: "CVE-2026-109283" page: "https://infrastack.ai/live/CVE-2026-109283" kind: "vulnerability" aliases: ["CVE-2026-109283", "GHSA-2rr4-q6pg-m5g3"] title: "Revoked users keep signing in via token exchange when roles are only in the ID token" severity: "medium" cvss: 5.4 epss: null exploited: false status: "open" category: "ai-tooling" products: [{"name": "open-webui", "fixed": ["0.11.4"], "affected": ">= 0.11.1, < 0.11.4", "ecosystem": "pypi"}] ecosystems: ["pypi"] tags: ["ai-tooling", "cwe-863", "entra-id", "oauth", "open-webui", "python", "self-hosted"] not_affected_if: ["browser-login-only", "default-config", "provider-returns-roles-in-userinfo"] published_at: "2026-09-27T16:14:42+00:00" first_seen_at: "2026-11-09T22:53:28+00:00" updated_at: "2026-11-09T23:01:09+00:00" sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-2rr4-q6pg-m5g3", "first_seen_at": "2026-11-09T22:53:28+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109283", "first_seen_at": "2026-11-09T23:10:12+00:00"}] exploit_sources: [] --- # Revoked users keep signing in via token exchange when roles are only in the ID token Link for people: https://infrastack.ai/live/CVE-2026-109283 (this .md is for agents) When Open WebUI's OAuth token exchange is enabled with role management, a user whose identity provider role was changed to a disallowed one can still get a working session if roles appear only in the ID token. The attacker keeps the role they held before, and gains nothing beyond their previous access. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - pypi:open-webui affected >= 0.11.1, < 0.11.4 fixed 0.11.4 ## How to check - Check that `ENABLE_OAUTH_TOKEN_EXCHANGE` and `ENABLE_OAUTH_ROLE_MANAGEMENT` are both set to `true`. - Check whether `OAUTH_ALLOWED_ROLES` is set and does not contain `*`. - Check whether your identity provider sends the roles claim only in the ID token and not in the userinfo response (Microsoft Entra ID app roles are the common case). - Check your installed version with `pip show open-webui`; affected builds are `>= 0.11.1, < 0.11.4`. ## Fix - `open-webui` (pypi): move to `0.11.4`. ## Timeline - 2026-11-09T22:53:28+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-2rr4-q6pg-m5g3 - 2026-11-09T23:10:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-109283 ## Documents - [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-2rr4-q6pg-m5g3 - [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/open-webui-0.11.1-before-0.11.4-authorization-bypass-via-oauth-token-exchange ## From the sources # Revoked users keep signing in via token exchange when roles are only in the ID token ## Summary The OAuth token exchange endpoint lets a user who already has a linked OAuth account swap a provider access token for an Open WebUI session. Since 0.11.1 it applies the OAuth role policy, but it only reads roles from the provider's userinfo response, and it only refuses a user when a roles claim is found. With an identity provider that sends roles only in the ID token (Microsoft Entra ID app roles are the common case), token exchange sees no roles and keeps the user's existing role, so a user whose provider role no longer satisfies the policy, and who is correctly refused at browser login, can still get a working session. ## Preconditions - `ENABLE_OAUTH_TOKEN_EXCHANGE=true` (default `false`). - `ENABLE_OAUTH_ROLE_MANAGEMENT=true` (default `false`), with `OAUTH_ALLOWED_ROLES` (default `user,admin`) not containing `*`. - The identity provider puts the roles claim only in the ID token and not in the userinfo response. - The attacker already has an Open WebUI account linked to their provider identity, and can still obtain a valid access token from the provider (their provider account is active, only their role changed). Deployments with either setting off, or whose provider returns roles in userinfo, are not affected. ## Impact A user the operator meant to lock out through the OAuth role policy keeps signing in through token exchange and keeps the role they held before, together with everything that role can reach. The attacker gains nothing beyond their previous access: an empty roles claim can neither grant admin nor change the role. Exploitation needs the non-default configuration above and a previously provisioned account. Browser SSO login is not affected and refuses the user as intended. ## Fix Fixed in 10d1cfe63, released in 0.11.4. Token exchange now also reads the roles claim from the exchanged token, and when role management is on and no roles claim can be read at all, it refuses the exchange. ## Root cause - Component: the OAuth token exchange endpoint (`POST /api/v1/auths/oauth/{provider}/token/exchange`) and the OAuth role policy it calls. - Affected builds: 0.11.1 through 0.11.3, the releases that added the role policy to token exchange. The role policy was written for browser login, where the ID token claims are merged into the user data before the policy runs, so "no roles claim" there means the provider genuinely sent none and keeping the current role is the documented behaviour. Token exchange never receives an ID token and builds the user data from userinfo alone, so for providers that only put roles in the ID token the policy always saw an empty claim and fell through to keeping the existing role instead of refusing. ## Proof of concept Reproduced on the 0.11.3 and 0.11.4 PyPI packages with a local OIDC provider that puts `roles` only in the ID token, `ENABLE_OAUTH_TOKEN_EXCHANGE=true`, `ENABLE_OAUTH_ROLE_MANAGEMENT=true` and an `OAUTH_ALLOWED_ROLES` list. 1. Sign in once through SSO while holding an allowed role, so the account is linked. 2. At the provider, change the user's role to one outside the allowed list. 3. Browser SSO login: refused with 403 on both versions. 4. Obtain an access token from the provider and send `POST /api/v1/auths/oauth/{provider}/token/exchange` with `{"token": ""}`. 5. On 0.11.3 the request returns 200 with a session token that works on `GET /api/v1/auths/`. On 0.11.4 it returns 403. Control: a user still holding an allowed role is allowed on both versions. ## Credits - `manus-pi`: reported the role policy bypass on token exchange for providers that send roles only in the ID token. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_