CVE-2026-59213: Open WebUI Model List Caching Flaw Exposes Permissions to Authenticated Users

Technical summary

In Open WebUI versions before 0.10.0, the get_all_models handlers in routers/openai.py and routers/ollama.py incorrectly pass a lambda function to the aiocache key parameter instead of using the proper key_builder mechanism. This causes per-user, permission-filtered model lists to collapse into a single static cache entry. During the cache TTL window, any authenticated caller receives whichever filtered model list was cached, potentially exposing one user's model permissions and available models to other users querying the same endpoint.

Business impact

Organizations deploying self-hosted Open WebUI as an internal AI platform may inadvertently expose model availability and permissions metadata across users. In multi-tenant or role-separated environments, this information leakage could reveal which models specific departments or security levels are authorized to use, aiding lateral reconnaissance or privilege escalation planning. The exposure is limited to metadata, not model outputs or data, but it does violate expected access controls and audit trails.

Affected systems

Open WebUI versions 0.6.27 through 0.9.x are affected. The vulnerability is present in both the OpenAI and Ollama router implementations. Version 0.10.0 and later contain the fix. Self-hosted deployments of Open WebUI are the only affected systems; the official hosted service does not apply.

Exploitability

Exploitation requires valid user authentication and is not readily automated without legitimate access credentials. However, once authenticated, an attacker needs only to call the get_all_models endpoint during the cache TTL window to observe another user's filtered model list. The CVSS 3.1 score of 3.5 (LOW) reflects the authentication requirement and limited confidentiality impact. Real-world exploitation likelihood depends on cache TTL configuration and user activity patterns.

Remediation

Upgrade Open WebUI to version 0.10.0 or later, which corrects the cache key handling to properly isolate per-user model lists. Administrators should review deployment documentation for any cache TTL tuning, as shorter TTLs further reduce the exposure window during any interim period before patching.

Patch guidance

Update Open WebUI to version 0.10.0 or later. Refer to the official Open WebUI release notes and security advisories for detailed upgrade procedures. Test the upgrade in a non-production environment first to confirm compatibility with custom configurations or integrations. Document the current version before upgrading to facilitate rollback if necessary.

Detection guidance

Review audit logs for the get_all_models endpoint (typically POST or GET requests to /api/v1/models or similar) to identify unusual access patterns across user accounts. Monitor cache hit rates and response timing anomalies that might suggest cross-user cache collisions. If available, inspect aiocache configuration and TTL settings in your Open WebUI deployment. Consider implementing request logging and correlation to detect when multiple users receive identical model lists in rapid succession, which would be atypical under normal use.

Why prioritize this

Despite a LOW CVSS score, this vulnerability merits prompt attention in multi-user or role-based deployments because it directly undermines access control expectations. Information about available AI models and permissions can inform attackers about organizational capabilities and security boundaries. The fix is mature (version 0.10.0), straightforward to deploy, and carries no known breaking changes, making remediation low-risk.

Risk score, explained

CVSS 3.1 score of 3.5 reflects: (1) Network vector—accessible remotely but requires internet connectivity to your Open WebUI instance; (2) High complexity—attacker must time requests within a cache TTL window and authenticate first; (3) Low privilege requirement—any valid user can trigger the leak; (4) Changed scope—the cached model list crosses user boundaries; (5) Low confidentiality impact—metadata exposure only, not data exfiltration. The LOW severity is appropriate for metadata leakage in an already-authenticated context, though business context may elevate urgency.

Frequently asked questions