GHSA-9rpj-v7hf-vv2w
MEDIUMGHSA-9rpj-v7hf-vv2w is a medium-severity (CVSS 6.3) CWE-863 vulnerability in open-webui. O3 Security confirms whether GHSA-9rpj-v7hf-vv2w is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Open WebUI: Authenticated users can target arbitrary configured Ollama backends via unguarded url_idx path parameter
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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.
Impact
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.
Affected / Patched
- Affected:
<= 0.9.5 - Patched:
>= 0.9.6
Fix
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | all versions | 0.9.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update open-webui to 0.9.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9rpj-v7hf-vv2w is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9rpj-v7hf-vv2w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9rpj-v7hf-vv2w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9rpj-v7hf-vv2w in your dependencies?
O3 detects GHSA-9rpj-v7hf-vv2w across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.