Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
Lifecycle Timeline
3DescriptionGitHub Advisory
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 to gpt-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)
AnalysisAI
Authenticated users can bypass model access controls in Open WebUI ≤0.8.12 to invoke restricted AI models via chained base_model_id references. Any user with default model creation permissions can create a wrapper model referencing a restricted base model (e.g., gpt-4-turbo with admin-only access), then query it to consume the admin's API credits and access premium model capabilities. This vulnerability enables cost escalation on pay-per-token backends (OpenAI, Anthropic, Azure) and defeats tiered access policies. GitHub advisory confirmed; patched in version 0.9.0. No active exploitation confirmed per available intelligence, but the attack path is straightforward for authenticated users with standard permissions.
Technical ContextAI
Open WebUI is a self-hosted web interface for large language models (Python-based, distributed via PyPI as pkg:pip/open-webui). The model chaining feature allows administrators to compose user-facing models that reference underlying base models (via base_model_id) to provide actual inference. The vulnerability stems from CWE-862 (Missing Authorization) in the access control pipeline: check_model_access in utils/models.py validates only the user-facing model ownership, not the chained base model. When a user sends a chat completion request to their wrapper model, main.py:1696-1711 resolves base_model_id and rewrites the payload to target the base model without re-checking permissions. The rewritten request is then dispatched to upstream providers (openai.py, ollama.py) using the admin-configured API key. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L indicates network-exploitable with low complexity once authenticated, causing high confidentiality impact (access to restricted model outputs), low integrity impact (unauthorized model usage), and low availability impact (resource consumption).
RemediationAI
Upgrade Open WebUI to version 0.9.0 or later immediately. The patch is available via PyPI (pip install --upgrade open-webui) and documented in the GitHub advisory at https://github.com/open-webui/open-webui/security/advisories/GHSA-9vvh-qmjx-p4q8 and https://github.com/advisories/GHSA-9vvh-qmjx-p4q8. If immediate upgrade is not feasible, implement compensating controls: (1) Revoke the default workspace.models permission from untrusted users to prevent model creation/import - note this breaks legitimate user model customization workflows. (2) Audit existing user-created models for unauthorized base_model_id references via database inspection (check models table for base_model_id fields pointing to restricted models) and delete violating entries. (3) Monitor API usage logs for unexpected traffic to restricted model endpoints originating from wrapper model IDs. (4) Consider disabling base_model_id chaining entirely if the feature is not operationally required - this requires code modification and testing. All compensating controls reduce functionality; version 0.9.0 is the only complete fix.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-30623
GHSA-9vvh-qmjx-p4q8