CVE-2026-44563

GHSA-rcvp-6fgw-c7fh MEDIUM
Published May 8, 2026

# 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`...

Full CISO analysis pending enrichment.

Affected Systems

Package Ecosystem Vulnerable Range Patched
open-webui pip <= 0.8.12 0.9.0
135.3K Pushed 8d ago 58% patched ~9d to patch Full package profile →

Do you use open-webui? You're affected.

Severity & Risk

CVSS 3.1
5.4 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
N/A

Attack Surface

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C Low
I None
A Low

Recommended Action

Patch available

Update open-webui to version 0.9.0

Compliance Impact

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-44563?

Open WebUI's Ollama Model Access Control Bypass via /api/generate, /api/embed, /api/embeddings, and /api/show

Is CVE-2026-44563 actively exploited?

No confirmed active exploitation of CVE-2026-44563 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-44563?

Update to patched version: open-webui 0.9.0.

What is the CVSS score for CVE-2026-44563?

CVE-2026-44563 has a CVSS v3.1 base score of 5.4 (MEDIUM).

Technical Details

NVD Description

# 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: ```python # /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 <alice_token>" \ -d '{"model": "llama3:70b", "prompt": "..."}' # View restricted model details and system prompt curl -X POST /ollama/api/show \ -H "Authorization: Bearer <alice_token>" \ -d '{"model": "llama3:70b"}' # Generate embeddings with restricted model curl -X POST /ollama/api/embed \ -H "Authorization: Bearer <alice_token>" \ -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)

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L

Timeline

Published
May 8, 2026
Last Modified
May 8, 2026
First Seen
May 8, 2026

Related Vulnerabilities