---
id: "CVE-2026-109296"
page: "https://infrastack.ai/live/CVE-2026-109296"
kind: "vulnerability"
aliases: ["CVE-2026-109296", "GHSA-hm62-64q2-6gxw"]
title: "Any authenticated user can reach disabled model provider backends via an explicit backend index"
severity: "medium"
cvss: 5.3
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "open-webui", "fixed": ["0.11.4"], "affected": "< 0.11.4", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-tooling", "cwe-639", "cwe-862", "ollama", "open-webui", "openai-compatible", "self-hosted"]
not_affected_if: ["no-user-role-accounts", "single-connection", "upgraded-0.11.4"]
published_at: "2026-09-27T19:33:41+00:00"
first_seen_at: "2026-11-09T22:53:27+00:00"
updated_at: "2026-11-09T23:10:12+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-hm62-64q2-6gxw", "first_seen_at": "2026-11-09T22:53:27+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109296", "first_seen_at": "2026-11-09T23:10:12+00:00"}]
exploit_sources: []
---

# Any authenticated user can reach disabled model provider backends via an explicit backend index

Link for people: https://infrastack.ai/live/CVE-2026-109296 (this .md is for agents)

Open WebUI's Ollama and OpenAI-compatible model listing routes accept a caller-chosen backend index and skip the check that the caller may use that connection. A signed-in account with the user role can make the server contact a disabled provider backend, and on two routes the request carries that connection's API key.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:open-webui affected < 0.11.4 fixed 0.11.4

## How to check

- Check the Open WebUI version with `pip show open-webui` or the image tag; versions below `0.11.4` are affected.
- Check whether more than one Ollama or OpenAI-compatible connection is configured in the admin settings.
- Check whether `DEFAULT_USER_ROLE` or signup grants the `user` role to new accounts.

## Fix

- Open WebUI: upgrade to `0.11.4` or later.

## Timeline

- 2026-11-09T22:53:27+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-hm62-64q2-6gxw
- 2026-11-09T23:10:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-109296

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-hm62-64q2-6gxw
- [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/open-webui-before-0.11.4-missing-authorization-via-backend-index-on-model-routes

## From the sources

# Any authenticated user can reach disabled model provider backends via an explicit backend index

## Summary

Several Ollama and OpenAI-compatible model listing routes accept a caller-supplied backend index and use it to select a connection directly from the administrator-configured provider list. No check is performed on whether the caller is permitted to reach that connection. Any account with the `user` role can therefore make the server issue requests to a provider backend it was never granted, including one the administrator has explicitly disabled, and can read back that backend's version string. Two of the affected routes send the request with the connection's configured API key attached.

## Preconditions

- More than one model provider connection configured, either Ollama backends or OpenAI-compatible connections. A deployment with a single connection loses nothing here, because the caller can only select a connection that is already the one in use.
- An account with the `user` role. `DEFAULT_USER_ROLE` defaults to `pending`, so an administrator must have approved the account or the deployment must be configured to grant `user` on signup. Administrator privileges are not required, and the affected behaviour is intended for administrators.
- No other knowledge is required. The index is a small integer and valid values can be found by trial.
- `BYPASS_MODEL_ACCESS_CONTROL` defaults to `false`. With the default, the catalogue returned by the affected routes is filtered by per-model access control, so no model names are disclosed. With the flag set to `true`, the catalogues of enabled connections are already visible to every account through the routes that take no index, but a disabled connection's catalogue is only reachable through the index, and so is sending inference to it.

## Impact

A non-administrator can direct the server to contact a provider backend outside the set it is entitled to use. This covers backends the administrator has switched off, which the equivalent routes that take no index correctly skip, and backends that serve only models the account has no access to. On two of the affected routes the outbound request carries that connection's configured API key, so the backend accepts it as an authorised call. The key itself is never returned to the caller.

The version string of any configured backend, including a disabled one, is returned to the caller verbatim. The routes that return a model catalogue disclose nothing under default configuration, because the upstream response is filtered by per-model access control before it is returned. An out-of-range index previously produced a different response from a valid one, which revealed how many connections are configured.

With `BYPASS_MODEL_ACCESS_CONTROL` enabled, the same missing check applied to the inference routes, so a non-administrator could send generation and embedding requests to a disabled backend and consume its capacity, rather than only listing it.

Nothing is written or deleted on any backend, no credential is disclosed to the caller, and no other account's data is exposed. The reachable destinations are limited to the connections the administrator configured, so no request can be steered to an address of the caller's choosing.

## Fix

Fixed in [#29619](https://github.com/open-webui/open-webui/pull/29619), completing an earlier change that shipped in 0.11.1. Selecting a provider connection by explicit index now requires an administrator on the affected listing routes, whether the index is given as a path segment or as a query parameter, matching the model management routes alongside them. The per-model backend check on the inference routes is no longer skipped when per-model access control is bypassed. The 0.11.1 change gated only the path form, so 0.11.1 to 0.11.3 remained reachable through the query parameter. Upgrading to 0.11.4 fully resolves the issue with no configuration change.

## Root cause

The affected surface is the Ollama tag listing, version and OpenAI-format model listing routes, and the OpenAI-compatible model listing route. Each is available to any verified account and accepts the backend index both as a trailing path segment and as a query parameter on the form that takes no index. Every released version before 0.11.4 carries the code.

An earlier fix introduced a check that a caller-supplied index must point at a backend actually serving the requested model, and applied it to the routes that run inference. The listing routes were not covered, because they name no model and therefore had nothing for that check to compare against. The question they needed answering was different, namely whether the caller may address a specific connection at all, and no control existed for it. The same earlier check also stepped aside entirely when per-model access control was bypassed. That left the inference routes open in that configuration for the one case per-model access control does not describe: an administrator having disabled the backend.

## Proof of concept

Two provider connections were configured through the administrator API, with index 1 marked disabled and holding a distinct API key. The backends were local HTTP servers standing in for real providers, recording every request they received along with its `Authorization` header. A second account was created with the `user` role.

As that account, requesting the tag listing, version and model listing routes with index 1, in both the path and query forms, returned HTTP 200. The disabled backend recorded each request, and the tag listing and OpenAI-compatible model listing arrived carrying the administrator's configured key for that connection. The version route returned the disabled backend's version string to the caller verbatim. An index beyond the end of the list produced a server error where a valid index produced a success, giving the number of configured connections.

With `BYPASS_MODEL_ACCESS_CONTROL` set to `true`, the same account sent a chat completion to index 1 and the disabled backend served it.

After the fix, every indexed listing request returns HTTP 401 and the indexed chat completion returns HTTP 403, and the disabled backend records nothing. Administrator access and the routes that take no index are unchanged.

## Credits

Reported by @ahkarl13.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_
