CVE-2026-44563

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

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:

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

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)

• 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

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

CVE-2026-44563 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.9.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-44563? CVE-2026-44563 is a medium-severity missing authorization vulnerability in open-webui (pip), affecting versions <= 0.8.12. It is fixed in 0.9.0. The application does not perform an authorization check before performing a sensitive operation.
2. How severe is CVE-2026-44563? CVE-2026-44563 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of open-webui are affected by CVE-2026-44563? open-webui (pip) versions <= 0.8.12 is affected.
4. Is there a fix for CVE-2026-44563? Yes. CVE-2026-44563 is fixed in 0.9.0. Upgrade to this version or later.
5. Is CVE-2026-44563 exploitable, and should I be worried? Whether CVE-2026-44563 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-44563 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-44563? Upgrade open-webui to 0.9.0 or later.