CVE-2026-29071: 
Python vulnerability analysis and mitigation

CVE-2026-29071 is an Insecure Direct Object Reference (IDOR) vulnerability in Open WebUI, a self-hosted AI platform, that allows any authenticated user to read other users' private memories and uploaded files via the /api/v1/retrieval/query/collection API endpoint. It affects all versions up to and including 0.8.5, and was patched in version 0.8.6. The vulnerability was disclosed on March 26, 2026, by researcher MariuszMaik. It carries a CVSS v3.1 base score of 3.1 (Low) per the GitHub Advisory, though Feedly reports an alternative score of 4.3 (Medium) (GitHub Advisory, Open WebUI Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the query_collection_handler function in backend/open_webui/routers/retrieval.py accepts a collection_names parameter and verifies only that the requester is an authenticated user (get_verified_user), but performs no ownership validation on the requested collections. Collection names follow predictable patterns — user-memory-{USER_UUID} for memories and file-{FILE_UUID} for uploaded files — making it trivial for an attacker to construct valid collection identifiers for other users. Additionally, the /api/v1/users/search endpoint exposes all user UUIDs, emails, names, and roles to any authenticated user, enabling straightforward enumeration of targets. A detailed PoC with concrete HTTP requests was included in the security advisory (Open WebUI Advisory).

Successful exploitation allows any authenticated user — without admin privileges — to read the full content and metadata of files uploaded by any other user, including administrators, and to access private LLM personalization memories when the experimental Memory feature is enabled. This constitutes a confidentiality breach affecting all platform users, with no impact on integrity or availability. The /api/v1/users/search endpoint further exposes user enumeration data (UUIDs, emails, roles), which can facilitate targeted attacks or account profiling (Open WebUI Advisory).

A proof-of-concept with detailed step-by-step HTTP requests is publicly available in the official security advisory, confirmed as high-confidence actionable exploit steps by Feedly threat intelligence. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.013% (2nd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Open WebUI Advisory, GitHub Advisory).

1. Obtain authentication token: Register or log in as any standard user on the target Open WebUI instance to obtain a valid Bearer token.
2. Enumerate users: Send a GET /api/v1/users/search request with the Bearer token. The response returns all users' UUIDs, emails, names, and roles — including admin accounts.

   GET /api/v1/users/search HTTP/1.1
   Host: <target>
   Authorization: Bearer <token>

3. Construct memory collection name: Using the target user's UUID (e.g., 81d2f94a-3dfb-479c-af98-e29f0f40c4ba), form the collection name user-memory-81d2f94a-3dfb-479c-af98-e29f0f40c4ba.
4. Read target's private memories: POST to /api/v1/retrieval/query/collection with the constructed collection name (requires Memory experimental feature to be enabled on the target account):

   POST /api/v1/retrieval/query/collection HTTP/1.1
   Host: <target>
   Authorization: Bearer <token>
   Content-Type: application/json
   
   {"collection_names": ["user-memory-81d2f94a-3dfb-479c-af98-e29f0f40c4ba"], "query": "test"}

5. Read target's uploaded files: If the target file UUID is known (e.g., via metadata leakage), construct file-{FILE_UUID} and POST to the same endpoint to retrieve full document content and metadata.

   {"collection_names": ["file-243bee10-49ad-466f-884b-67b6b3d74968"], "query": "test"}

   (Open WebUI Advisory)

• Network: Repeated GET /api/v1/users/search requests from a single authenticated user, especially in rapid succession (user enumeration behavior); POST /api/v1/retrieval/query/collection requests containing collection_names values referencing UUIDs that do not belong to the authenticated user's account.
• Logs: API access logs showing a non-admin user querying user-memory-{UUID} or file-{UUID} collections belonging to other users; multiple distinct UUIDs queried by the same session token in a short timeframe.
• Application Behavior: Queries to /api/v1/retrieval/query/collection returning documents with created_by fields mismatching the requesting user's ID. (Open WebUI Advisory)

Upgrade Open WebUI to version 0.8.6 or later, which patches the missing authorization check in query_collection_handler. If immediate patching is not possible, restrict network-level access to the /api/v1/retrieval/query/collection and /api/v1/users/search endpoints to trusted users or admin roles only via a reverse proxy or API gateway. The suggested code fix involves adding ownership validation: checking that user-memory-{UUID} collections are only accessible by the matching user (or admins), and verifying file ownership before allowing access to file-{UUID} collections (Open WebUI Advisory, GitHub Advisory).