CVE-2026-54021

Several direct, index-addressed Ollama proxy routes accept a caller-supplied url_idx
path parameter and use it as a raw index into the admin-configured OLLAMA_BASE_URLS
list. Access control on these routes validates only whether the user may use the
requested model, never which backend the request is routed to. Any authenticated
user can append an arbitrary url_idx to force their request onto an Ollama backend
they were never authorized to reach, including internal, higher-privilege, or
explicitly admin-disabled backends.

Affected endpoints

All indexed Ollama routes that resolve the backend through get_ollama_url():

POST /ollama/api/chat/{url_idx}
POST /ollama/api/generate/{url_idx}
POST /ollama/api/embed/{url_idx}
POST /ollama/api/embeddings/{url_idx}
POST /ollama/v1/chat/completions/{url_idx}
POST /ollama/v1/completions/{url_idx}
POST /ollama/v1/messages/{url_idx}
POST /ollama/v1/responses/{url_idx}

Root cause

backend/open_webui/routers/ollama.py, get_ollama_url() consults the
model-to-backend allow-list (OLLAMA_MODELS[model]["urls"]) only when url_idx is
omitted. When the caller supplies url_idx, that mapping is skipped and the value is
used directly as an index:

async def get_ollama_url(request: Request, model: str, url_idx: Optional[int] = None):
    if url_idx is None:
        models = request.app.state.OLLAMA_MODELS
        if model not in models:
            raise HTTPException(...)
        url_idx = random.choice(models[model].get("urls", []))
    url = request.app.state.config.OLLAMA_BASE_URLS[url_idx]   # caller-controlled, no authz
    return url, url_idx

The outbound request is then sent to that backend using the backend's own configured
API key. Backends an admin has disabled (OLLAMA_API_CONFIGS["<idx>"].enable = false)
are hidden from model discovery but remain reachable through the indexed route, because
the disabled state is never re-checked at request time.

Affected / Patched

• Affected: <= 0.9.5
• Patched: >= 0.9.6

A verified, non-admin user with read access to any single model can:

• route requests to internal / higher-capability / restricted Ollama backends in
  multi-backend deployments, bypassing backend-level isolation;
• reach backends the admin has explicitly disabled;
• have those requests authenticated with the target backend's configured API key
  (the key is used server-side; it is not returned to the attacker);
• consume the restricted backend's compute.

There is no cross-user data disclosure and no exfiltration of the backend credential
itself; the impact is unauthorized access to, and use of, restricted backend resources.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-54021 has a CVSS score of 6.3 (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.6); upgrading removes the vulnerable code path.

Kodem intelligence

0.9.6 adds validate_ollama_backend_idx(), invoked on every indexed route (directly and
via get_ollama_url()), which returns 403 for any non-admin caller-supplied url_idx
that is not in the requested model's allowed urls. Because disabled backends are absent
from every model's urls, the same check also blocks routing to disabled backends.

1. What is CVE-2026-54021? CVE-2026-54021 is a medium-severity incorrect authorization vulnerability in open-webui (pip), affecting versions <= 0.9.5. It is fixed in 0.9.6. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-54021? CVE-2026-54021 has a CVSS score of 6.3 (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-54021? open-webui (pip) versions <= 0.9.5 is affected.
4. Is there a fix for CVE-2026-54021? Yes. CVE-2026-54021 is fixed in 0.9.6. Upgrade to this version or later.
5. Is CVE-2026-54021 exploitable, and should I be worried? Whether CVE-2026-54021 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-54021 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-54021? Upgrade open-webui to 0.9.6 or later.