CVE-2026-59213: Open WebUI cache leak exposes

Q: Is CVE-2026-59213 actively exploited?

No confirmed active exploitation of CVE-2026-59213 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-59213?

1) Upgrade Open WebUI to 0.10.0 or later, where get_all_models now uses a proper per-user key_builder for aiocache. 2) Until patched, if the deployment enforces per-user model restrictions, consider temporarily reducing or disabling the aiocache TTL on the affected model-list routes to shrink the exposure window. 3) Review deployment topology: single-tenant instances or instances where all users share identical model access are not meaningfully impacted and can patch on normal cadence. 4) No specific log signature exists for this leak (it manifests as a normal-looking API response), so detection is limited to code-level verification of the patched key_builder logic post-upgrade rather than runtime monitoring.

Q: What systems are affected by CVE-2026-59213?

This vulnerability affects the following AI/ML architecture patterns: model serving, self-hosted LLM platforms, multi-tenant AI gateways.

Q: What is the CVSS score for CVE-2026-59213?

CVE-2026-59213 has a CVSS v3.1 base score of 3.5 (LOW). The EPSS exploitation probability is 0.37%.

CISO Take

A caching bug in Open WebUI's model-listing endpoints (routers/openai.py and routers/ollama.py) passed a static lambda instead of a per-user key_builder to aiocache, so permission-filtered model lists got cached under a shared key and could be served to a different authenticated user during the TTL window. The blast radius is narrow — this is a low-severity confidentiality issue (CVSS 3.5, C:L/I:N/A:N) with high attack complexity, no public exploit, no Nuclei template, and it sits well outside CISA KEV, so an EPSS score in the top 83rd percentile still translates to a very low absolute exploitation probability. The real exposure is in multi-tenant Open WebUI deployments where different users or teams are entitled to different model sets (private fine-tunes, premium/paid models, restricted internal endpoints) — a low-privileged user could learn what models a higher-privileged peer has access to, which is reconnaissance value rather than data exfiltration. There are 130 other CVEs recorded against this package and no downstream dependents tracked, consistent with open-webui being a terminal self-hosted app rather than an embedded library. Action: upgrade to Open WebUI 0.10.0 (fixed in PR #25783 / commit 0fc630b), and in the interim, deployments that rely on per-user model access restrictions for compliance or tenant isolation should treat any model-list response served to a user as unverified until patched, or reduce/disable the aiocache TTL on those routes as a stopgap.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Low risk overall: CVSS 3.5 with C:L/I:N/A:N reflects a narrow confidentiality leak (model list metadata only, not chat content, credentials, or model weights). Exploitability is constrained by AC:H — the attacker must be an authenticated low-privileged user (PR:L) and must query the endpoint within the same cache TTL window as a victim's request, which is a timing-dependent, non-trivial condition to engineer reliably. No public PoC, no Nuclei template, not in CISA KEV, and EPSS remains near-zero in absolute terms despite the top-83rd-percentile ranking. The primary risk driver is deployment context: single-tenant or homogeneous-access Open WebUI instances see essentially no real-world impact, while multi-tenant instances that gate model access by user/role (a common enterprise pattern) face a genuine confidentiality gap until patched.

How does the attack unfold?

Initial Access

Attacker holds a valid low-privileged Open WebUI account in a multi-tenant deployment with differentiated model permissions.

AML.T0012

Cache Timing Exploitation

Attacker repeatedly calls the get_all_models endpoint hoping to land within the TTL window right after a higher-privileged user's request populated the shared, non-per-user cache key.

Information Disclosure

The victim's permission-filtered model list is returned to the attacker, revealing which private or premium models the victim's account/team can access.

AML.T0014

Follow-on Targeting

Disclosed model names/IDs inform further reconnaissance or targeting of internal/premium model endpoints not otherwise visible to the attacker's account tier.

AML.T0013

Initial Access

Attacker holds a valid low-privileged Open WebUI account in a multi-tenant deployment with differentiated model permissions.

AML.T0012

Cache Timing Exploitation

Attacker repeatedly calls the get_all_models endpoint hoping to land within the TTL window right after a higher-privileged user's request populated the shared, non-per-user cache key.

Information Disclosure

The victim's permission-filtered model list is returned to the attacker, revealing which private or premium models the victim's account/team can access.

AML.T0014

Follow-on Targeting

Disclosed model names/IDs inform further reconnaissance or targeting of internal/premium model endpoints not otherwise visible to the attacker's account tier.

AML.T0013

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	>= 0.6.27, < 0.10.0	`0.10.0`
153.3K 3 dependents Pushed 3d ago 83% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1

3.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 29% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

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 Network

AC High

PR Low

UI None

S Changed

C Low

I None

A None

What should I do?

1 step

1) Upgrade Open WebUI to 0.10.0 or later, where get_all_models now uses a proper per-user key_builder for aiocache. 2) Until patched, if the deployment enforces per-user model restrictions, consider temporarily reducing or disabling the aiocache TTL on the affected model-list routes to shrink the exposure window. 3) Review deployment topology: single-tenant instances or instances where all users share identical model access are not meaningfully impacted and can patch on normal cadence. 4) No specific log signature exists for this leak (it manifests as a normal-looking API response), so detection is limited to code-level verification of the patched key_builder logic post-upgrade rather than runtime monitoring.

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?

Data Leakage Privacy Violation API Inference AML.T0014 - Discover AI Model Family

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2 - Access control for AI system components and information

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-59213?

A caching bug in Open WebUI's model-listing endpoints (routers/openai.py and routers/ollama.py) passed a static lambda instead of a per-user key_builder to aiocache, so permission-filtered model lists got cached under a shared key and could be served to a different authenticated user during the TTL window. The blast radius is narrow — this is a low-severity confidentiality issue (CVSS 3.5, C:L/I:N/A:N) with high attack complexity, no public exploit, no Nuclei template, and it sits well outside CISA KEV, so an EPSS score in the top 83rd percentile still translates to a very low absolute exploitation probability. The real exposure is in multi-tenant Open WebUI deployments where different users or teams are entitled to different model sets (private fine-tunes, premium/paid models, restricted internal endpoints) — a low-privileged user could learn what models a higher-privileged peer has access to, which is reconnaissance value rather than data exfiltration. There are 130 other CVEs recorded against this package and no downstream dependents tracked, consistent with open-webui being a terminal self-hosted app rather than an embedded library. Action: upgrade to Open WebUI 0.10.0 (fixed in PR #25783 / commit 0fc630b), and in the interim, deployments that rely on per-user model access restrictions for compliance or tenant isolation should treat any model-list response served to a user as unverified until patched, or reduce/disable the aiocache TTL on those routes as a stopgap.

Is CVE-2026-59213 actively exploited?

No confirmed active exploitation of CVE-2026-59213 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59213?

1) Upgrade Open WebUI to 0.10.0 or later, where get_all_models now uses a proper per-user key_builder for aiocache. 2) Until patched, if the deployment enforces per-user model restrictions, consider temporarily reducing or disabling the aiocache TTL on the affected model-list routes to shrink the exposure window. 3) Review deployment topology: single-tenant instances or instances where all users share identical model access are not meaningfully impacted and can patch on normal cadence. 4) No specific log signature exists for this leak (it manifests as a normal-looking API response), so detection is limited to code-level verification of the patched key_builder logic post-upgrade rather than runtime monitoring.

What systems are affected by CVE-2026-59213?

This vulnerability affects the following AI/ML architecture patterns: model serving, self-hosted LLM platforms, multi-tenant AI gateways.

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

CVE-2026-59213 has a CVSS v3.1 base score of 3.5 (LOW). The EPSS exploitation probability is 0.37%.

What is the AI security impact?

Affected AI Architectures

model servingself-hosted LLM platformsmulti-tenant AI gateways

MITRE ATLAS Techniques

AML.T0014 Discover AI Model Family

Compliance Controls Affected

ISO 42001: A.6.2.2

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.6.27 before 0.10.0, get_all_models handlers in routers/openai.py and routers/ollama.py passed a lambda to aiocache key instead of key_builder, causing permission-filtered per-user model lists to share a static cache entry and exposing one user’s model list to another caller during the TTL window. This issue is fixed in version 0.10.0.

Exploitation Scenario

In a multi-tenant Open WebUI deployment where Team A has access to a restricted or premium model set and Team B does not, an attacker with a low-privileged Team B account repeatedly polls the model-list endpoint (/api/models or the openai/ollama router equivalents). If a Team A user's request populates the shared cache entry within the TTL window, the attacker's subsequent request returns Team A's permission-filtered model list instead of their own — revealing which private, internal, or premium models the organization has deployed. This is reconnaissance rather than direct compromise: the disclosed model names/IDs could inform a follow-on targeted attack (e.g., probing a newly revealed internal model endpoint) but do not themselves grant access to those models or their outputs.

Weaknesses (CWE)

CWE-524 Use of Cache Containing Sensitive Information Primary CWE-524 Use of Cache Containing Sensitive Information

CWE-524 — Use of Cache Containing Sensitive Information: The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

[Architecture and Design] Protect information stored in cache.
[Architecture and Design] Do not store unnecessarily sensitive information in the cache.

Source: MITRE CWE corpus.