CVE-2026-59212: Open WebUI: Model meta.knowledge read-only file access can be upgraded to file write/delete

The earlier fix added _verify_knowledge_file_access() in backend/open_webui/routers/models.py. It checks only that the caller has read access to a file before accepting the file ID into a model's meta.knowledge. But has_access_to_file() in utils/access_control/files.py grants any access type, including write, if a model the user can write lists that file ID in meta.knowledge.

So a user who can read a victim's file through a knowledge-base read grant creates or edits their own model, adds the file ID, and now passes the write check. The advisory's PoV shows write is denied before the model step and allowed after it.

The attacker needs a normal account, Models workspace access and a read-only KB grant covering the file. No admin rights, Tools or Functions code is involved. The confirmed sinks are POST /api/v1/files/{id}/rename, POST /api/v1/files/{id}/data/content/update and DELETE /api/v1/files/{id}. The result is lost or tampered documents for the owner. Content that feeds RAG can be altered, so model answers drawn from the file can change.

The open-webui pip package, versions >= 0.9.6, < 0.10.0. Exposure needs multiple users, knowledge bases shared with read grants, and users who hold Models workspace access.

pip show open-webui

For Docker, check the image tag. To audit exposure, review which non-admin users have Models workspace permission and which knowledge bases carry read grants.

Upgrade to open-webui 0.10.0.

pip install --upgrade open-webui==0.10.0

The fix is in pull request 26032. The advisory's remediation advice is to require file ownership or admin when attaching an individual file to a model, and to stop the model meta.knowledge branch of has_access_to_file() from granting write access. No workaround is listed. Until you upgrade, limit Models workspace permission to trusted users.

Look for models whose meta.knowledge holds type: file entries pointing at files the model owner did not upload. Then check access logs for POST /api/v1/files/{id}/rename, POST /api/v1/files/{id}/data/content/update or DELETE /api/v1/files/{id} made by a user who is not the file's owner or an admin. Files that vanished or changed in a shared knowledge base are a sign.

Summary

Current main and v0.9.6 still allow an authenticated user to turn read-only access to another user's file into write/delete access by attaching that file ID to an attacker-controlled workspace model.

This is an incomplete-fix variant of GHSA-vjqm-6gcc-62cr. The current fix adds _verify_knowledge_file_access(), but the validator only checks has_access_to_file(file_id, "read", user). The file write/delete routes later trust has_access_to_file(file_id, "write", user), and that function grants access through any writable model whose meta.knowledge contains the file ID.

The PoV includes a negative control showing the current validator rejects an inaccessible arbitrary file ID. The residual issue is narrower: a file ID that is readable only through a KB read grant is accepted into direct model file metadata, then the same model metadata satisfies later file write/delete checks.

Technical Details

backend/open_webui/routers/models.py::_verify_knowledge_file_access() accepts model meta.knowledge file entries when the caller can read the file:

if not await has_access_to_file(file_id, 'read', user, db=db):
    raise HTTPException(...)

backend/open_webui/utils/access_control/files.py::has_access_to_file() then uses attacker-writable model metadata as a source for any requested access type:

for model in await Models.get_models_by_user_id(user.id, permission=access_type, db=db):
    knowledge_items = getattr(model.meta, 'knowledge', None) or []
    for item in knowledge_items:
        if isinstance(item, dict) and item.get('type') == 'file' and item.get('id') == file.id:
            return True

For access_type="write", the attacker-owned model satisfies the model query, so the victim file becomes writable even though the attacker only had read access through the KB grant.

This crosses another user's integrity and availability boundary, not just the attacker's own account. Before model metadata is involved, the attacker can read the file through a KB grant but cannot write it. After the model metadata entry is accepted, the same file becomes writable/deletable.

The official docs distinguish attached knowledge permissions: knowledge-base collections may use explicit read grants, while individual files are owner/admin-only. This issue lets a read grant to a KB become direct write/delete authority over an individual file.

This is also consistent with the documented RBAC model: resource grants have separate read and write permissions, where write means the user can update or delete the resource. The exploit starts from a read-only KB grant and reaches file write/delete without a corresponding file owner/admin/write authorization.

The required Models workspace access is not root-equivalent in Open WebUI's documentation. The policy's root-equivalent warning applies to Tools/Functions code execution. This report does not use Tools/Functions, custom Python, admin actions, or a legacy-only path.

Impact

An authenticated non-admin user with Models workspace access and read-only access to a victim file through a knowledge-base grant can create/import/update a model that references the file, then rename, overwrite, or delete the victim user's file through write-gated file routes.

Confirmed sinks in current head:

• POST /api/v1/files/{id}/rename
• POST /api/v1/files/{id}/data/content/update
• DELETE /api/v1/files/{id}

Suggested severity: High.

Suggested CVSS:

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

Suggested CWE:

CWE-863: Incorrect Authorization

I am not claiming Critical severity because the attacker must be authenticated, must have Models workspace access, and must already have read-only access to the victim file through a KB grant. The High score is based on the post-condition: that limited read access becomes destructive cross-user file write/delete.

Appendix: AI Disclosure

Appendix: Local PoV

The PoV is local-only. It does not start a server, send network traffic, or use a real database. It loads and executes the current-head function bodies for:

• has_access_to_file()
• _verify_knowledge_file_access()
• delete_file_by_id()

Run from the harness root:

uv run python attached-evidence/poc/pov_openwebui_model_file_read_to_write.py

Observed output:

{
  "confirmed": true,
  "control_inaccessible_file_rejected_by_validator": true,
  "control_read_allowed_via_kb_read_grant": true,
  "control_write_allowed_before_model_laundering": false,
  "model_metadata_validator_passed_with_read_only_access": true,
  "write_allowed_after_attacker_owned_model_contains_file": true,
  "delete_route_result": {
    "message": "File deleted successfully"
  },
  "deleted_file_ids": [
    "victim-file"
  ]
}

This demonstrates expected versus actual behavior:

• Expected: a user with only read access through a KB grant cannot mutate the victim file.
• Actual: after the read-only file ID is accepted into attacker-owned model metadata, the same user satisfies the file write/delete guard and deletes the victim file.

Appendix: Remediation

Recommended defense-in-depth fix:

1. In _verify_knowledge_file_access(), require direct file ownership or admin for type: "file" model knowledge entries. Do not accept indirect KB read access as sufficient authority to attach an individual file to a model.
2. In has_access_to_file(), do not let the model meta.knowledge branch grant write access to files. Model-attached knowledge should be read-only unless the caller separately owns/administers the underlying file or has an explicit write-capable file authorization path.
3. Add regression tests covering the KB-read control, the blocked model attach, and rename/update/delete denial for the victim file.