Jul 24, 2026·5 min read·112 visits
Open WebUI's improper use of the aiocache decorator collapses per-user model lists into a single cache key, allowing low-privileged users to leak restricted model metadata during the 1-second TTL window.
An authorization bypass and cross-session cache leakage vulnerability exists in the model-listing backend of Open WebUI. The flaw stems from a configuration error in the @cached decorator of the aiocache library, which maps all unique user session queries to a single static cache key.
Open WebUI is an extensible, self-hosted user interface designed to interact with large language models via backend routers such as OpenAI and Ollama. The platform manages authorization boundaries, ensuring that users only view and interact with AI models they are explicitly permitted to access.
CVE-2026-59213 identifies an authorization bypass and cross-session cache leakage vulnerability in the model-listing endpoints of Open WebUI. The flaw allows authenticated, low-privileged users to view the metadata and configuration options of restricted models. This disclosure bypasses configured access control policies.
The weakness lies in the implementation of the backend caching layer. Specifically, the application utilizes the aiocache library to store the list of available models. Because of a configuration error, the cache key evaluation collapses all user sessions into a single static cache entry.
The root cause of CVE-2026-59213 is a syntax-level configuration error of the @cached decorator provided by the aiocache library. In backend/open_webui/routers/openai.py and backend/open_webui/routers/ollama.py, developers attempted to implement per-user caching to optimize the retrieval of available models while maintaining user boundaries.
To achieve this, the developers passed a lambda function to the key parameter of the @cached decorator. The lambda was designed to output a unique cache key based on the authenticated user's ID, such as openai_all_models_{user.id}. However, the aiocache library expects a static string for the key parameter.
When a callable object like a lambda function is passed to the key parameter, aiocache does not execute the function at runtime. Instead, it uses the string representation of the lambda function object itself as a static, constant cache key identifier. Consequently, every user query evaluates to the exact same cache key, causing a global cache collision across all sessions.
Analyzing the implementation within backend/open_webui/routers/openai.py clarifies the operational difference between the vulnerable and patched versions. The vulnerable implementation used a lambda function directly inside the key parameter:
# Vulnerable implementation
@cached(
ttl=MODELS_CACHE_TTL,
key=lambda _, user: f'openai_all_models_{user.id}' if user else 'openai_all_models',
)
async def get_all_models(request: Request, user: UserModel) -> dict[str, list]:
log.info('get_all_models()')In this configuration, the cache key evaluates to a reference of the lambda function. This collapses all requests into a shared cache space. The patch resolves this issue by replacing the key parameter with key_builder, which is specifically designed to execute callables on each request:
# Patched implementation in commit 0fc630b34b2899599dabffffa012afd47599aa75
@cached(
ttl=MODELS_CACHE_TTL,
# key_builder (not key) is the per-call hook in aiocache 0.12
key_builder=lambda _func, request, user=None: f'openai_all_models_{user.id}' if user else 'openai_all_models',
)
async def get_all_models(request: Request, user: UserModel) -> dict[str, list]:
log.info('get_all_models()')The key_builder callback accepts the wrapped function, the HTTP request, and any keyword arguments, correctly generating a unique identifier for each user session.
Exploitation of CVE-2026-59213 does not require complex payloads but depends on timing. Because the cache Time-To-Live (TTL) is set to a short duration (typically 1 second, controlled by MODELS_CACHE_TTL), an attacker must query the target endpoint concurrently with a privileged user.
An authenticated attacker with low privileges can execute a script to repeatedly request the /api/models endpoint (for example, every 500 milliseconds). If an administrator or privileged user requests their model list within that active 1-second caching window, the backend generates and caches the privileged model list under the shared static key. The attacker's subsequent request hits this cache entry.
The attacker receives the cached HTTP response payload containing the complete list of available models, exposing metadata, private deployment adapters, local API endpoints, or custom models that should otherwise be restricted.
The security impact of CVE-2026-59213 is classified as low, with a CVSS v3.1 base score of 3.5. The primary consequence is the unauthorized disclosure of sensitive system configuration and metadata. An attacker cannot use this vulnerability to alter system state, execute code, or read private conversation history.
However, the leakage of model names, custom prompt templates, or integrated system backend configurations provides valuable intelligence for targeted attacks. In high-security environments, revealing the existence of specialized fine-tuned models or local API endpoints represents a failure of defense-in-depth.
Because exploitation is bound to a 1-second caching window, mass automated exploitation is difficult. The attack requires active timing correlation, making targeted exploitation inside internal networks or multi-tenant deployments the primary risk scenario.
To remediate CVE-2026-59213, administrators must upgrade Open WebUI to version 0.10.0 or higher. The patch updates both openai.py and ollama.py to use key_builder instead of key within the @cached decorator.
In environments where immediate patching is not feasible, administrators should consider disabling model caching by setting MODELS_CACHE_TTL to 0 or a negative value if supported by the configuration. This forces the application to query the database and apply authorization checks dynamically for every request.
Development teams using aiocache or similar frameworks should run static analysis tools to verify that dynamic parameters (such as lambda functions or callbacks) are only passed to decorator fields designed to execute them. Passing a callback to a static key configuration is a common design pattern error that silently compromises authentication boundaries.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Open WebUI Open WebUI | >= 0.6.27, < 0.10.0 | 0.10.0 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-524: Use of Cache Containing Sensitive Information |
| Attack Vector | Network (AV:N) |
| CVSS Severity Score | 3.5 (Low) |
| EPSS Score | 0.00296 |
| Impact | Information Disclosure / Access Control Bypass |
| Exploit Status | PoC (Proof of Concept) |
| KEV Status | Not Listed |
The product stores sensitive information in a cache that is accessible to unauthorized actors.
A path traversal vulnerability (CWE-22) in Contao CMS allows unauthenticated remote attackers to bypass directory boundary restrictions in ImagesController and access files within the project directory.
Contao Open Source CMS versions 4.0.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 contain a Cross-Site Request Forgery (CSRF) vulnerability in backend parameter handling. The `RequestTokenListener` component validates anti-CSRF tokens solely for HTTP POST requests, while GET-based declarative guards run only when an `act` parameter is present in the query string. Consequently, custom backend actions dispatched via alternative parameters such as `key=` can execute without CSRF token verification when triggered by an authenticated user.
Contao CMS versions 4.1.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 fail to validate form submission tokens and enforce rate limiting when processing activation email resend requests via HTTP POST, enabling resource exhaustion and account state enumeration.
An information disclosure vulnerability in Contao CMS allows unauthenticated site visitors to view protected page titles, URLs, and text excerpts through search queries when protected page indexing is disabled after previously being enabled.
In Vikunja prior to version 2.6.0, relation creation via the CalDAV endpoint fails to invoke the TaskRelation.CanCreate authorization check. This missing access control allows an authenticated user to establish unauthorized relationships and perform write operations against any task, provided its unique identifier (UID) is known.
A cross-project information disclosure vulnerability in Vikunja allows authenticated users with read access to one project to view private task details from unauthorized projects via subtask expansion parameters.