GHSA-2xwm-4h2q-ggfx

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,...