IDOR: Retrieval API Bypasses Knowledge Base Access Controls

Author: Andrew Orr aorr@tenable.com

Summary

_validate_collection_access() (PR #22109) checks the user-memory-* and file-* collection name prefixes but does not check knowledge base collections, which use raw UUIDs as collection names. Any authenticated user who knows a private knowledge base UUID can read its content through the retrieval query endpoints, even though the knowledge API correctly denies that user access. The same gap affects the retrieval write endpoints (/process/text, /process/file, /process/files/batch, /process/web, /process/youtube), allowing an attacker to inject content into or overwrite another user's knowledge base.

Reproduced on main at commit 4d058a125 (v0.8.11) on March 26, 2026.

Severity

• CWE-639: Authorization Bypass Through User-Controlled Key
• CVSS 3.1: 7.5 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) -- AC:H because exploitation requires knowing a target UUID; I:H and A:H because the write path allows poisoning or destruction of another user's knowledge base

Default Configuration Reachability

Reachable in default configuration. All affected endpoints require only get_verified_user, not get_admin_user, so any non-admin account in a typical multi-user deployment can reach them. The only prerequisite beyond authentication is knowledge of a target knowledge base UUID, which is reflected in the AC:H score. However, KB UUIDs are stable identifiers that leak through normal usage rather than secrets (see Prerequisites below).

Root Cause

Knowledge base embeddings are stored in vector DB collections named with the knowledge base's UUID (e.g., 550e8400-e29b-41d4-a716-446655440000). The _validate_collection_access function only blocks two specific prefixes:

# backend/open_webui/routers/retrieval.py lines 2330-2355
def...