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 through normal knowledge/file routes.

Reproduction Steps

Use a local Open WebUI instance with two verified users:

1. As user owner, create a knowledge base.
2. Grant user reader read access to the knowledge base, but do not grant write access.
3. As 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.

4. As 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

[email protected]
metadata={"knowledge_id":"<knowledge_id>"}

5. Observe that the upload request succeeds and returns the uploaded file record.
6. As owner, request the knowledge-base files:

GET /api/v1/knowledge/<knowledge_id>/files
Authorization: Bearer <owner token>

7. Observe that attacker-note.txt appears in the target knowledge base even though reader did not have write access.
8. As owner, request the file content:

GET /api/v1/files/<attacker_file_id>/content
Authorization: Bearer <owner token>

9. Observe that the file is retrievable because has_access_to_file derives access from the unauthorized knowledge-base membership.

Expected Behavior

The upload auto-link path should enforce the same authorization contract as /api/v1/knowledge/{id}/file/add:

• The target knowledge base must exist.
• The caller must be the knowledge owner, an admin, or have write access.
• The supplied directory_id, if present, must belong to the target knowledge base.
• The KnowledgeFile association should only be inserted after authorization and processing succeed.

Actual Behavior

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.

Suggested Fix

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:

1. Load the target knowledge base.
2. Require owner/admin/write access before calling Knowledges.add_file_to_knowledge_by_id.
3. Validate that directory_id, if supplied, belongs to the same knowledge base.
4. 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.