중간취약점
Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)
GHSA-7r7x-gjvr-448g · CVE-2026-59217 · PYSEC-2026-3593 · 갱신 2026. 8. 4.
GHSA-7r7x-gjvr-448g · CVE-2026-59217 · PYSEC-2026-3593 · 갱신 2026. 8. 4.
| 생태계 | 패키지 | 수정 버전 |
|---|---|---|
| PyPI | open-webui | 0.10.0 |
Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)
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.
open-webui/open-webui02dc3e689ceac915a870b373318b99c029ddf603package.json: 0.9.6open-webuiA read-only knowledge-base collaborator can perform a write operation against that knowledge base by attaching arbitrary uploaded files.
Security impact:
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.
The normal single-file knowledge add endpoint checks write permission before processing or inserting the relationship:
backend/open_webui/routers/knowledge.pyadd_file_to_knowledge_by_idwrite access.The upload auto-link path does not perform the same check:
backend/open_webui/routers/files.pyprocess_uploaded_fileknowledge_id from upload metadata and immediately call Knowledges.add_file_to_knowledge_by_id(...).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.pyadd_file_to_knowledge_by_idKnowledgeFile 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.pyprocess_file_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.pyhas_access_to_fileSo once the attacker's file is inserted into the target KnowledgeFile table, target knowledge-base readers/owners can see and fetch that file through normal knowledge/file routes.
Use a local Open WebUI instance with two verified users:
owner, create a knowledge base.reader read access to the knowledge base, but do not grant write access.reader, confirm the normal add-file endpoint is blocked:POST /api/v1/knowledge/<knowledge_id>/file/add
Authorization: Bearer <reader token>
Content-Type: application/json
{"file_id":"<reader-owned-file-id>"}
Expected and observed behavior for the normal route: it rejects the request because reader lacks knowledge-base write access.
reader, upload a new file with the same target knowledge ID embedded in upload metadata:POST /api/v1/files/?process=true&process_in_background=false
Authorization: Bearer <reader token>
Content-Type: multipart/form-data
file=@attacker-note.txt
metadata={"knowledge_id":"<knowledge_id>"}
owner, request the knowledge-base files:GET /api/v1/knowledge/<knowledge_id>/files
Authorization: Bearer <owner token>
attacker-note.txt appears in the target knowledge base even though reader did not have write access.owner, request the file content:GET /api/v1/files/<attacker_file_id>/content
Authorization: Bearer <owner token>
has_access_to_file derives access from the unauthorized knowledge-base membership.The upload auto-link path should enforce the same authorization contract as /api/v1/knowledge/{id}/file/add:
write access.directory_id, if present, must belong to the target knowledge base.KnowledgeFile association should only be inserted after authorization and processing succeed.metadata.knowledge_id causes Knowledges.add_file_to_knowledge_by_id(...) to insert a KnowledgeFile row before write authorization is checked. The later collection write validation can fail, but the unauthorized membership row remains committed.
Move knowledge-base authorization before the insert in the upload auto-link path. The upload path should share the same write-access and directory validation logic used by the dedicated knowledge endpoints.
One safe pattern:
Knowledges.add_file_to_knowledge_by_id.directory_id, if supplied, belongs to the same knowledge base.