Open WebUI: missing authorization

# Open WebUI upload metadata can add files to knowledge bases without write permission ## Summary Open WebUI's file upload background processing trusts the client-supplied `metadata.knowledge_id` value and inserts a `knowledge_file` association before validating that the uploading user has write access to the target knowledge base. A verified user with only read access to a knowledge base can upload an arbitrary file and set `metadata={"knowledge_id":"<target knowledge id>"}`. The normal `/api/v1/knowledge/{id}/file/add` endpoint correctly requires knowledge-base write access, but the upload auto-link path bypasses that authorization check. The immediate result is unauthorized modification of the target knowledge base's file membership. The attached attacker-controlled file becomes visible through `/api/v1/knowledge/{id}/files`, and readers/owners of that knowledge base can retrieve the file through the normal file endpoints because file access is derived from `KnowledgeFile` membership. ## Affected Version - Repository: `open-webui/open-webui` - Tested source commit: `02dc3e689ceac915a870b373318b99c029ddf603` - Package version observed in `package.json`: `0.9.6` - Package name: `open-webui` ## Impact A read-only knowledge-base collaborator can perform a write operation against that knowledge base by attaching arbitrary uploaded files. Security impact: - Unauthorized knowledge-base membership modification. - Integrity impact on shared knowledge-base file listings. - Attacker-controlled files become readable to other users who can read the target knowledge base. - If an owner/admin later reprocesses or globally reindexes the knowledge base, the unauthorized file can be indexed into the knowledge collection, turning the membership bypass into RAG/content poisoning. This is not an unauthenticated issue. It requires a verified Open WebUI account and a valid target knowledge-base ID. The clearest exploit path is a user who legitimately has read access to a knowledge base but not write access. ## Source Evidence The normal single-file knowledge add endpoint checks write permission before processing or inserting the relationship: - `backend/open_webui/routers/knowledge.py` - `add_file_to_knowledge_by_id` - Lines 714-728 reject callers who are not owner, admin, or granted `write` access. - Lines 750-766 then process and insert the file only after that authorization gate. The upload auto-link path does not perform the same check: - `backend/open_webui/routers/files.py` - `process_uploaded_file` - Lines 178-186 read `knowledge_id` from upload metadata and immediately call `Knowledges.add_file_to_knowledge_by_id(...)`. - Lines 187-192 call `process_file(... collection_name=knowledge_id ...)` after the insert. The model method inserts the relationship without validating the caller's write access to the knowledge base: - `backend/open_webui/models/knowledge.py` - `add_file_to_knowledge_by_id` - Lines 646-677 create and commit a `KnowledgeFile` row for the supplied `knowledge_id`, `file_id`, and `user_id`. The later vector write check exists, but it runs too late: - `backend/open_webui/routers/retrieval.py` - `process_file` - Lines 1587-1592 call `_validate_collection_access(..., access_type='write')` when a collection is supplied. Because the unauthorized `KnowledgeFile` row is already committed before that check runs, the failed vector processing does not undo the knowledge-base file association. The upload code catches the exception at `backend/open_webui/routers/files.py` lines 194-195 and logs a warning while leaving the row in place. The unauthorized relationship affects file access decisions: - `backend/open_webui/utils/access_control/files.py` - `has_access_to_file` - Lines 41-53 grant file access when a file is associated with a knowledge base the user can access. So once the attacker's file is inserted into the target `KnowledgeFile` table, target knowledge-base readers/owners can see and fetch that file th

CVSS 3.1

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Severity from

GitHub (reviewed advisory)

Weakness

CWE-862, CWE-863

Also known as

CVE-2026-59217, PYSEC-2026-3593

• github.com/open-webui/open-webui/security/advisories/GHSA-7r7x-gjvr-448g
• nvd.nist.gov/vuln/detail/CVE-2026-59217
• github.com/open-webui/open-webui/pull/26001
• github.com/open-webui/open-webui/commit/b7626f05fb92b24ab923ad81a037071ebd5623d1
• github.com/open-webui/open-webui
• github.com/open-webui/open-webui/releases/tag/v0.10.0