{"id":"CVE-2026-59217","aliases":["GHSA-7r7x-gjvr-448g"],"title":"Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)","summary":"Open WebUI: Upload `metadata.knowledge_id` bypasses the knowledge-base write-access check (read-only users can add files to KB)","severity":"medium","cvss":4.3,"cwe":["CWE-862","CWE-863"],"vendor":"open-webui","product":"open-webui","ecosystem":"pip","affected":["open-webui < 0.10.0"],"patched":["open-webui 0.10.0"],"published":"2026-07-24","updated":"2026-07-24","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-7r7x-gjvr-448g","references":[{"url":"https://github.com/open-webui/open-webui/security/advisories/GHSA-7r7x-gjvr-448g"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59217"},{"url":"https://github.com/open-webui/open-webui/pull/26001"},{"url":"https://github.com/open-webui/open-webui/commit/b7626f05fb92b24ab923ad81a037071ebd5623d1"},{"url":"https://github.com/open-webui/open-webui/releases/tag/v0.10.0"},{"url":"https://github.com/advisories/GHSA-7r7x-gjvr-448g"}],"tags":["ghsa","pip"],"epss":0.00372,"epssPercentile":0.31079,"ingestedAt":"2026-07-24T17:34:27.221Z","slug":"CVE-2026-59217","body":"## Overview\n\n# 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\":\"<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.\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/<knowledge_id>/file/add\nAuthorization: Bearer <reader token>\nContent-Type: application/json\n\n{\"file_id\":\"<reader-owned-file-id>\"}\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 <reader token>\nContent-Type: multipart/form-data\n\nfile=@attacker-note.txt\nmetadata={\"knowledge_id\":\"<knowledge_id>\"}\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/<knowledge_id>/files\nAuthorization: Bearer <owner token>\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/<attacker_file_id>/content\nAuthorization: Bearer <owner token>\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.\n\n## Affected packages\n\n- `open-webui < 0.10.0`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `open-webui 0.10.0`","depth":"sunlit","depthScore":24,"depthScoreParts":{"impact":23.7,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}