Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI

GHSA-9vvh-qmjx-p4q8

HIGH

GHSA-9vvh-qmjx-p4q8 is a high-severity (CVSS 7.6) vulnerability in open-webui. O3 Security confirms whether GHSA-9vvh-qmjx-p4q8 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Open WebUI's Base Model Routing Bypasses Access Control via Model Chaining

Also known asCVE-2026-44555PYSEC-2026-2719
Published
May 8, 2026
Updated
Jul 13, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Real-World Exposure

1 pkg affected
🐍open-webui

Real-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

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_id

Attack Scenario

  1. Admin provisions a premium/restricted model gpt-4-turbo-restricted and configures access grants so only the "ML Engineers" group can use it.
  2. 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.
  3. Attacker now owns cheap-assistant. check_model_access(attacker, cheap-assistant) passes trivially because they are the owner.
  4. Attacker sends:
    POST /api/chat/completions
    {"model": "cheap-assistant", "messages": [...]}
    
  5. At main.py:1696, the pipeline resolves cheap-assistant.base_model_id to gpt-4-turbo-restricted, rewrites payload["model"] to the base model ID, and dispatches the upstream request with the admin-configured API key for the backend.
  6. 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.models permission, granted to all users by default)
  • A restricted base model must exist on the instance (the target of the chain)

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIopen-webuiall versions0.9.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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-9vvh-qmjx-p4q8 is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-9vvh-qmjx-p4q8 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-9vvh-qmjx-p4q8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

# 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_mod
O3 Security · Impact-Aware SCA

Is GHSA-9vvh-qmjx-p4q8 in your dependencies?

O3 detects GHSA-9vvh-qmjx-p4q8 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.