Open WebUI Cache Key Permission Bypass in Model List

Executive Summary

The vulnerability CVE-2026-59213 is a cross-user model-list exposure issue in the Open WebUI application. It occurs because the caching mechanism in the get_all_models handlers in routers/openai.py and routers/ollama.py was misconfigured. Instead of using the correct key_builder parameter to generate a unique cache key per user, the code used the key parameter with a lambda function, which aiocache treats as a static key. This caused all users to share the same cache entry, allowing one user to see another user's permission-filtered model list during the cache's time-to-live window.

The root cause is a misunderstanding of how the aiocache library handles the key parameter, which does not invoke the callable per request but uses it as a constant key. The fix involved replacing key= with key_builder= and modifying the lambda function to include user-specific information in the cache key, ensuring each user gets their own cached model list.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to unauthorized exposure of one user's model list to another user or an anonymous caller during the cache's time-to-live period. Although the exposure is limited to the cached model lists and is timing-dependent (typically within a 1-second window), it means that sensitive or permission-filtered model information could be inadvertently shared across users.

The severity is rated as Low with a CVSS score of 3.5 because the exposure is incidental, not attacker-controlled, and does not allow modification or deletion of data.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by verifying if the Open WebUI application versions between 0.6.27 and before 0.10.0 are in use, specifically checking the caching implementation in the get_all_models handlers in routers/openai.py and routers/ollama.py.

You can inspect the source code or deployed files to see if the @cached decorator uses the parameter key= with a lambda function instead of key_builder=. If key= is used, it indicates the vulnerable caching mechanism.

To detect the issue dynamically, you could monitor responses to model list requests from different users and check if the model lists are improperly shared or identical across users within the cache TTL window (default 1 second).

There are no specific commands provided in the resources, but general steps include:

• Check the version of Open WebUI running (should be 0.10.0 or later to be fixed).
• Review the source code or deployed files for the caching decorator usage in routers/openai.py and routers/ollama.py.
• Perform test requests as different users to the get_all_models endpoint and compare the returned model lists for cross-user data leakage.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade the Open WebUI application to version 0.10.0 or later, where the vulnerability is fixed.

If upgrading is not immediately possible, review and modify the caching implementation in routers/openai.py and routers/ollama.py to replace the @cached decorator's key= parameter with key_builder=, ensuring the cache key is dynamically generated per user.

Specifically, the lambda function used for caching should have the signature (func, request, user=None) and build a unique cache key incorporating the user ID to prevent cross-user cache sharing.

Additionally, consider reducing the cache TTL to minimize the exposure window, although this is a temporary mitigation.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability causes cross-user exposure of permission-filtered model lists due to a caching misconfiguration, which means one user could access another user's data temporarily during the cache's time-to-live window.

Such unintended data exposure can potentially violate data privacy principles found in regulations like GDPR and HIPAA, which require strict access controls and protection of personal or sensitive information.

However, the severity is rated as low (CVSS 3.5) and the exposure is incidental and timing-dependent, which may limit the scope of compliance impact.

The issue was fixed by ensuring proper per-user cache key generation, preventing unauthorized cross-user data access.

Useful 0 Not Useful 0