GHSA-RCVP-6FGW-C7FH

Vulnerability from github – Published: 2026-05-08 19:52 – Updated: 2026-05-08 19:52
VLAI?
Summary
Open WebUI's Ollama Model Access Control Bypass via /api/generate, /api/embed, /api/embeddings, and /api/show
Details

Ollama Model Access Control Bypass via /api/generate, /api/embed, /api/embeddings, and /api/show

Affected Component

Ollama proxy endpoints missing model access control: - backend/open_webui/routers/ollama.py (lines 955-995, generate_completion) - backend/open_webui/routers/ollama.py (lines 835-881, embed) - backend/open_webui/routers/ollama.py (lines 891-937, embeddings) - backend/open_webui/routers/ollama.py (lines 791-820, show_model_info)

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions with Ollama model access control support.

Description

Four Ollama proxy endpoints accept any model name from the user and forward the request to the Ollama backend without checking whether the user is authorized to access that model. These endpoints only require get_verified_user (any authenticated non-pending user) and validate that the model exists in the full unfiltered model list, but never check AccessGrants.has_access().

This is in direct contrast with the /ollama/api/chat endpoint (line 1101-1122) which correctly validates model access grants and returns 403 for unauthorized users:

# /api/chat (line 1101-1122) — CORRECTLY checks access
if not bypass_filter and user.role == 'user':
    user_group_ids = {group.id for group in Groups.get_groups_by_member_id(user.id)}
    if not (
        user.id == model_info.user_id
        or AccessGrants.has_access(
            user_id=user.id, resource_type='model',
            resource_id=model_info.id, permission='read',
            user_group_ids=user_group_ids,
        )
    ):
        raise HTTPException(status_code=403, detail='Model not found')

# /api/generate (line 955-995) — NO access check at all
# /api/embed (line 835-881) — NO access check at all
# /api/embeddings (line 891-937) — NO access check at all
# /api/show (line 791-820) — NO access check at all

CVSS 3.1 Breakdown

Metric Value Rationale
Attack Vector Network (N) Exploited remotely via API calls
Attack Complexity Low (L) Single API call with a known model name
Privileges Required Low (L) Requires any authenticated user account
User Interaction None (N) No victim interaction required
Scope Unchanged (U) Impact within the Ollama model access boundary
Confidentiality Low (L) /api/show exposes restricted model details including system prompts and parameters
Integrity None (N) No data modification
Availability Low (L) Unauthorized consumption of GPU/compute resources on restricted models

Attack Scenario

  1. Admin configures model access control, restricting llama3:70b to the "ML Engineers" group. Regular user Alice is only authorized for llama3:8b.
  2. Alice knows the restricted model name (model names are predictable — llama3:70b, mistral:latest, etc.).
  3. Alice calls the unprotected endpoints directly: ```bash # Run completions on restricted model curl -X POST /ollama/api/generate \ -H "Authorization: Bearer " \ -d '{"model": "llama3:70b", "prompt": "..."}'

# View restricted model details and system prompt curl -X POST /ollama/api/show \ -H "Authorization: Bearer " \ -d '{"model": "llama3:70b"}'

# Generate embeddings with restricted model curl -X POST /ollama/api/embed \ -H "Authorization: Bearer " \ -d '{"model": "llama3:70b", "input": "..."}' ``` 4. All requests succeed and are proxied to Ollama without any access control check.

Impact

  • Model access control is silently ineffective for four out of five Ollama proxy endpoints
  • Unauthorized users can consume GPU/compute resources on restricted models (cost and capacity impact in multi-user deployments)
  • /api/show exposes restricted model configurations including system prompts, parameters, templates, and license information
  • Admins have a false sense of security — access restrictions appear to work via the main chat interface but are trivially bypassed via direct API calls

Preconditions

  • Ollama must be configured as a backend
  • Admin must have configured model access control (not using BYPASS_MODEL_ACCESS_CONTROL=true)
  • Attacker must know the restricted model name (model names follow predictable conventions)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.12"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T19:52:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Ollama Model Access Control Bypass via /api/generate, /api/embed, /api/embeddings, and /api/show\n\n## Affected Component\n\nOllama proxy endpoints missing model access control:\n- `backend/open_webui/routers/ollama.py` (lines 955-995, `generate_completion`)\n- `backend/open_webui/routers/ollama.py` (lines 835-881, `embed`)\n- `backend/open_webui/routers/ollama.py` (lines 891-937, `embeddings`)\n- `backend/open_webui/routers/ollama.py` (lines 791-820, `show_model_info`)\n\n## Affected Versions\n\nCurrent main branch (commit `6fdd19bf1`) and likely all versions with Ollama model access control support.\n\n## Description\n\nFour Ollama proxy endpoints accept any model name from the user and forward the request to the Ollama backend without checking whether the user is authorized to access that model. These endpoints only require `get_verified_user` (any authenticated non-pending user) and validate that the model exists in the full unfiltered model list, but never check `AccessGrants.has_access()`.\n\nThis is in direct contrast with the `/ollama/api/chat` endpoint (line 1101-1122) which correctly validates model access grants and returns 403 for unauthorized users:\n\n```python\n# /api/chat (line 1101-1122) \u2014 CORRECTLY checks access\nif not bypass_filter and user.role == \u0027user\u0027:\n    user_group_ids = {group.id for group in Groups.get_groups_by_member_id(user.id)}\n    if not (\n        user.id == model_info.user_id\n        or AccessGrants.has_access(\n            user_id=user.id, resource_type=\u0027model\u0027,\n            resource_id=model_info.id, permission=\u0027read\u0027,\n            user_group_ids=user_group_ids,\n        )\n    ):\n        raise HTTPException(status_code=403, detail=\u0027Model not found\u0027)\n\n# /api/generate (line 955-995) \u2014 NO access check at all\n# /api/embed (line 835-881) \u2014 NO access check at all\n# /api/embeddings (line 891-937) \u2014 NO access check at all\n# /api/show (line 791-820) \u2014 NO access check at all\n```\n\n## CVSS 3.1 Breakdown\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network (N) | Exploited remotely via API calls |\n| Attack Complexity | Low (L) | Single API call with a known model name |\n| Privileges Required | Low (L) | Requires any authenticated user account |\n| User Interaction | None (N) | No victim interaction required |\n| Scope | Unchanged (U) | Impact within the Ollama model access boundary |\n| Confidentiality | Low (L) | `/api/show` exposes restricted model details including system prompts and parameters |\n| Integrity | None (N) | No data modification |\n| Availability | Low (L) | Unauthorized consumption of GPU/compute resources on restricted models |\n\n## Attack Scenario\n\n1. Admin configures model access control, restricting `llama3:70b` to the \"ML Engineers\" group. Regular user Alice is only authorized for `llama3:8b`.\n2. Alice knows the restricted model name (model names are predictable \u2014 `llama3:70b`, `mistral:latest`, etc.).\n3. Alice calls the unprotected endpoints directly:\n   ```bash\n   # Run completions on restricted model\n   curl -X POST /ollama/api/generate \\\n     -H \"Authorization: Bearer \u003calice_token\u003e\" \\\n     -d \u0027{\"model\": \"llama3:70b\", \"prompt\": \"...\"}\u0027\n\n   # View restricted model details and system prompt\n   curl -X POST /ollama/api/show \\\n     -H \"Authorization: Bearer \u003calice_token\u003e\" \\\n     -d \u0027{\"model\": \"llama3:70b\"}\u0027\n\n   # Generate embeddings with restricted model\n   curl -X POST /ollama/api/embed \\\n     -H \"Authorization: Bearer \u003calice_token\u003e\" \\\n     -d \u0027{\"model\": \"llama3:70b\", \"input\": \"...\"}\u0027\n   ```\n4. All requests succeed and are proxied to Ollama without any access control check.\n\n## Impact\n\n- Model access control is silently ineffective for four out of five Ollama proxy endpoints\n- Unauthorized users can consume GPU/compute resources on restricted models (cost and capacity impact in multi-user deployments)\n- `/api/show` exposes restricted model configurations including system prompts, parameters, templates, and license information\n- Admins have a false sense of security \u2014 access restrictions appear to work via the main chat interface but are trivially bypassed via direct API calls\n\n## Preconditions\n\n- Ollama must be configured as a backend\n- Admin must have configured model access control (not using `BYPASS_MODEL_ACCESS_CONTROL=true`)\n- Attacker must know the restricted model name (model names follow predictable conventions)",
  "id": "GHSA-rcvp-6fgw-c7fh",
  "modified": "2026-05-08T19:52:42Z",
  "published": "2026-05-08T19:52:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-rcvp-6fgw-c7fh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI\u0027s Ollama Model Access Control Bypass via /api/generate, /api/embed, /api/embeddings, and /api/show"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…