CVE-2026-44555: Open WebUI's Base Model Routing Bypasses Access Control via Model Chaining
Base Model Routing Bypasses Access Control via Model Chaining Affected Component Model chaining via basemodelid: - backend/openwebui/routers/models.py (lines 170-214, createnewmodel) - backend/openwebui/routers/models.py (lines 254-308, importmodels) - backend/openwebui/main.py (lines 1696-1711, base model resolution in chat completion) - backend/openwebui/routers/openai.py (lines 1032-1037, base model payload…
Published May 8, 2026 · Updated May 15, 2026
Affected packages
open-webui
- Ecosystem
- PyPI
- Affected
- <= 0.8.12
- Fixed in
- 0.9.0
- Check
pip show open-webui
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
Base Model Routing Bypasses Access Control via Model Chaining
Affected Component
Model chaining via base_model_id:
backend/open_webui/routers/models.py(lines 170-214,create_new_model)backend/open_webui/routers/models.py(lines 254-308,import_models)backend/open_webui/main.py(lines 1696-1711, base model resolution in chat completion)backend/open_webui/routers/openai.py(lines 1032-1037, base model payload rewrite)backend/open_webui/routers/ollama.py(lines 1086-1090, base model payload rewrite)backend/open_webui/utils/models.py(line 380,check_model_access— checks user-facing model only)
Affected Versions
Current main branch (commit 6fdd19bf1) and likely all versions with the model chaining (base_model_id) feature.
Description
Open WebUI supports model composition via base_model_id: a user-defined model (e.g., "Cheap Assistant") can reference an existing base model (e.g., "gpt-4-turbo-restricted") that provides the actual inference capability. When a user queries the composed model, the access control pipeline verifies the user has access to the composed model but never re-verifies access to the chained base model.
Additionally, the model creation and import endpoints accept arbitrary base_model_id values without checking that the caller has access to that base model. Combined, this allows any user with the default model creation permission to create a model that chains to a restricted base model — and then invoke it, causing the server to dispatch the request to the restricted base model using the admin-configured API key.
# utils/models.py:380 — access check runs against the user-facing model only
def check_model_access(user, model):
if user.role == 'user':
...check access grants on `model`...
# main.py:1696-1711 — base model resolved without access check
base_model = request.app.state.MODELS.get(model.info.base_model_id)
if base_model:
# payload["model"] is rewritten to base_model.id
# but no check_model_access(user, base_model) is performed
# openai.py:1032-1037 / ollama.py:1086-1090 — the rewritten payload is dispatched
payload['model'] = base_model_idAttack Scenario
- Admin provisions a premium/restricted model
gpt-4-turbo-restrictedand configures access grants so only the "ML Engineers" group can use it. - Attacker (a regular user not in that group) calls: ``
POST /api/v1/models/create { "id": "cheap-assistant", "name": "Cheap Assistant", "base_model_id": "gpt-4-turbo-restricted", "params": {}, "meta": {} }`The creation endpoint does not validate the attacker's access togpt-4-turbo-restricted`. - Attacker now owns
cheap-assistant.check_model_access(attacker, cheap-assistant)passes trivially because they are the owner. - Attacker sends: ``
POST /api/chat/completions {"model": "cheap-assistant", "messages": [...]}`` - At
main.py:1696, the pipeline resolvescheap-assistant.base_model_idtogpt-4-turbo-restricted, rewritespayload["model"]to the base model ID, and dispatches the upstream request with the admin-configured API key for the backend. - The attacker receives responses from the restricted model, bypassing the access grant policy.
The same bypass is available via the import endpoint, which additionally allows overwriting existing models (see related finding on model import ownership).
Impact
- Regular users can query restricted models by chaining through a self-owned wrapper model
- Access control on
gpt-4-turbo-restricted(or equivalent paid/tiered/internal models) becomes silently ineffective - Direct cost impact on pay-per-token backends (OpenAI, Anthropic, Azure) — the admin's API key is used for requests the admin intended to forbid
- Creates a false sense of security — the admin sees access restrictions work through the standard model selector but not through user-created chains
Preconditions
- Attacker must have model creation permission (default
workspace.modelspermission, granted to all users by default) - A restricted base model must exist on the instance (the target of the chain)
Credited to Classic298.
References
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More Open WebUI vulnerabilities
All Open WebUI entriesCVE-2026-87011
Open WebUI: Unauthenticated requests can stall the server via uncached OIDC fetches in back-channel logout
high7.5Sep 10, 2026CVE-2026-87012
Open WebUI: Any authenticated user can suppress calendar alerts instance-wide via a non-numeric alert value
medium4.3Sep 10, 2026CVE-2026-87013
Open WebUI: Any authenticated user can start a non-terminating request via a folder parent cycle
medium4.3Sep 10, 2026CVE-2026-87014
Open WebUI: Admin demoted through SSO role sync keeps read and write access to all users' notes
medium6.5Sep 10, 2026CVE-2026-87015
Open WebUI: A user's session cookies are sent to tool servers configured for bearer authentication
medium6.8Sep 10, 2026CVE-2026-87016
Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite
high8.1Sep 10, 2026
