{"id":"PYSEC-2026-3593","summary":"Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)","details":"# Open WebUI upload metadata can add files to knowledge bases without write permission\n\n## Summary\n\nOpen 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.\n\nA verified user with only read access to a knowledge base can upload an arbitrary file and set `metadata={\"knowledge_id\":\"\u003ctarget knowledge id\u003e\"}`. 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.\n\nThe 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.\n\n## Affected Version\n\n- Repository: `open-webui/open-webui`\n- Tested source commit: `02dc3e689ceac915a870b373318b99c029ddf603`\n- Package version observed in `package.json`: `0.9.6`\n- Package name: `open-webui`\n\n## Impact\n\nA read-only knowledge-base collaborator can perform a write operation against that knowledge base by attaching arbitrary uploaded files.\n\nSecurity impact:\n\n- Unauthorized knowledge-base membership modification.\n- Integrity impact on shared knowledge-base file listings.\n- Attacker-controlled files become readable to other users who can read the target knowledge base.\n- 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.\n\nThis 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.\n\n## Source Evidence\n\nThe normal single-file knowledge add endpoint checks write permission before processing or inserting the relationship:\n\n- `backend/open_webui/routers/knowledge.py`\n- `add_file_to_knowledge_by_id`\n- Lines 714-728 reject callers who are not owner, admin, or granted `write` access.\n- Lines 750-766 then process and insert the file only after that authorization gate.\n\nThe upload auto-link path does not perform the same check:\n\n- `backend/open_webui/routers/files.py`\n- `process_uploaded_file`\n- Lines 178-186 read `knowledge_id` from upload metadata and immediately call `Knowledges.add_file_to_knowledge_by_id(...)`.\n- Lines 187-192 call `process_file(... collection_name=knowledge_id ...)` after the insert.\n\nThe model method inserts the relationship without validating the caller's write access to the knowledge base:\n\n- `backend/open_webui/models/knowledge.py`\n- `add_file_to_knowledge_by_id`\n- Lines 646-677 create and commit a `KnowledgeFile` row for the supplied `knowledge_id`, `file_id`, and `user_id`.\n\nThe later vector write check exists, but it runs too late:\n\n- `backend/open_webui/routers/retrieval.py`\n- `process_file`\n- Lines 1587-1592 call `_validate_collection_access(..., access_type='write')` when a collection is supplied.\n\nBecause 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.\n\nThe unauthorized relationship affects file access decisions:\n\n- `backend/open_webui/utils/access_control/files.py`\n- `has_access_to_file`\n- Lines 41-53 grant file access when a file is associated with a knowledge base the user can access.\n\nSo 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.\n\n## Reproduction Steps\n\nUse a local Open WebUI instance with two verified users:\n\n1. As user `owner`, create a knowledge base.\n2. Grant user `reader` read access to the knowledge base, but do not grant write access.\n3. As `reader`, confirm the normal add-file endpoint is blocked:\n\n```http\nPOST /api/v1/knowledge/\u003cknowledge_id\u003e/file/add\nAuthorization: Bearer \u003creader token\u003e\nContent-Type: application/json\n\n{\"file_id\":\"\u003creader-owned-file-id\u003e\"}\n```\n\nExpected and observed behavior for the normal route: it rejects the request because `reader` lacks knowledge-base write access.\n\n4. As `reader`, upload a new file with the same target knowledge ID embedded in upload metadata:\n\n```http\nPOST /api/v1/files/?process=true&process_in_background=false\nAuthorization: Bearer \u003creader token\u003e\nContent-Type: multipart/form-data\n\nfile=@attacker-note.txt\nmetadata={\"knowledge_id\":\"\u003cknowledge_id\u003e\"}\n```\n\n5. Observe that the upload request succeeds and returns the uploaded file record.\n6. As `owner`, request the knowledge-base files:\n\n```http\nGET /api/v1/knowledge/\u003cknowledge_id\u003e/files\nAuthorization: Bearer \u003cowner token\u003e\n```\n\n7. Observe that `attacker-note.txt` appears in the target knowledge base even though `reader` did not have write access.\n8. As `owner`, request the file content:\n\n```http\nGET /api/v1/files/\u003cattacker_file_id\u003e/content\nAuthorization: Bearer \u003cowner token\u003e\n```\n\n9. Observe that the file is retrievable because `has_access_to_file` derives access from the unauthorized knowledge-base membership.\n\n## Expected Behavior\n\nThe upload auto-link path should enforce the same authorization contract as `/api/v1/knowledge/{id}/file/add`:\n\n- The target knowledge base must exist.\n- The caller must be the knowledge owner, an admin, or have `write` access.\n- The supplied `directory_id`, if present, must belong to the target knowledge base.\n- The `KnowledgeFile` association should only be inserted after authorization and processing succeed.\n\n## Actual Behavior\n\n`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.\n\n## Suggested Fix\n\nMove 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.\n\nOne safe pattern:\n\n1. Load the target knowledge base.\n2. Require owner/admin/write access before calling `Knowledges.add_file_to_knowledge_by_id`.\n3. Validate that `directory_id`, if supplied, belongs to the same knowledge base.\n4. Run vector processing before inserting the membership row, or wrap processing plus insertion in a transaction/compensating cleanup so a denied or failed process cannot leave a stale unauthorized row.","aliases":["CVE-2026-59217","GHSA-7r7x-gjvr-448g"],"modified":"2026-08-04T14:30:29.521746534Z","published":"2026-08-04T11:34:42.894513Z","references":[{"type":"WEB","url":"https://github.com/open-webui/open-webui/security/advisories/GHSA-7r7x-gjvr-448g"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59217"},{"type":"WEB","url":"https://github.com/open-webui/open-webui/pull/26001"},{"type":"WEB","url":"https://github.com/open-webui/open-webui/commit/b7626f05fb92b24ab923ad81a037071ebd5623d1"},{"type":"PACKAGE","url":"https://github.com/open-webui/open-webui"},{"type":"WEB","url":"https://github.com/open-webui/open-webui/releases/tag/v0.10.0"},{"type":"PACKAGE","url":"https://pypi.org/project/open-webui"},{"type":"ADVISORY","url":"https://github.com/advisories/GHSA-7r7x-gjvr-448g"}],"affected":[{"package":{"name":"open-webui","ecosystem":"PyPI","purl":"pkg:pypi/open-webui"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.10.0"}]}],"versions":["0.1.124","0.1.125","0.2.0","0.2.1","0.2.2","0.2.3","0.2.4","0.2.5","0.3.0","0.3.1","0.3.10","0.3.12","0.3.13","0.3.14","0.3.15","0.3.16","0.3.17","0.3.17.dev2","0.3.17.dev3","0.3.17.dev4","0.3.17.dev5","0.3.18","0.3.19","0.3.2","0.3.20","0.3.21","0.3.22","0.3.23","0.3.24","0.3.25","0.3.26","0.3.27","0.3.27.dev1","0.3.27.dev2","0.3.27.dev3","0.3.28","0.3.29","0.3.3","0.3.30","0.3.30.dev1","0.3.30.dev2","0.3.31","0.3.31.dev1","0.3.32","0.3.33","0.3.33.dev1","0.3.34","0.3.35","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9","0.4.0","0.4.0.dev1","0.4.0.dev2","0.4.1","0.4.2","0.4.3","0.4.4","0.4.5","0.4.6","0.4.6.dev1","0.4.7","0.4.8","0.5.0","0.5.0.dev1","0.5.0.dev2","0.5.1","0.5.10","0.5.11","0.5.12","0.5.13","0.5.14","0.5.15","0.5.16","0.5.17","0.5.18","0.5.19","0.5.2","0.5.20","0.5.3","0.5.3.dev1","0.5.4","0.5.5","0.5.6","0.5.7","0.5.8","0.5.9","0.6.0","0.6.1","0.6.10","0.6.11","0.6.12","0.6.13","0.6.14","0.6.15","0.6.16","0.6.18","0.6.19","0.6.2","0.6.20","0.6.21","0.6.22","0.6.23","0.6.24","0.6.25","0.6.26","0.6.26.dev1","0.6.27","0.6.28","0.6.29","0.6.3","0.6.30","0.6.31","0.6.32","0.6.33","0.6.34","0.6.35","0.6.36","0.6.37","0.6.38","0.6.39","0.6.4","0.6.40","0.6.41","0.6.42","0.6.43","0.6.5","0.6.6","0.6.6.dev1","0.6.7","0.6.8","0.6.9","0.7.0","0.7.1","0.7.2","0.8.0","0.8.1","0.8.10","0.8.11","0.8.12","0.8.2","0.8.3","0.8.4","0.8.5","0.8.6","0.8.7","0.8.8","0.8.9","0.9.0","0.9.1","0.9.2","0.9.3","0.9.4","0.9.5","0.9.6"],"database_specific":{"source":"https://github.com/pypa/advisory-database/blob/main/vulns/open-webui/PYSEC-2026-3593.yaml"}}],"schema_version":"1.8.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N"}]}