GHSA-vjqm-6gcc-62cr Open WebUI: Forged model meta.knowledge allows cross-user file read and deletion
SummaryOpen WebUI lets a user who can create, update, or import workspace models store arbitrary `meta.knowledge` entries on their model without checking whether they own or can read the referenced files. Open WebUI then treats `meta.knowledge` entries of type `file` as an authorization source in two places: the built-in `view_file` tool reads the file's extracted text, and `has_access_to_file()`'s model branch authorizes the file content and file delete endpoints. A malicious model owner can therefore attach another user's file ID to their model metadata and read or delete that private file.ImpactSecurity boundary crossed: file confidentiality and integrity.An authenticated attacker needs the `workspace.models` or `workspace.models_import` permission (or write access to an existing model) and a victim file ID. With those, for a file they do not own and cannot otherwise read, the attacker can:read the file's extracted text (up to `100000` characters per `view_file` call from `file.data.content`),read the file's content via `GET /api/v1/files/{id}/content`, anddelete the file via `DELETE /api/v1/files/{id}`.Root Cause`ModelMeta` allows extra metadata fields and `ModelForm` accepts that metadata without a validator for `meta.knowledge` file access:Model creation only checks the caller's model-workspace permission and then stores the form data:The insert sink persists the supplied `meta`:When built-in tools are assembled, `meta.knowledge` is passed through as `__model_knowledge__`, and any `file` entry enables `view_file`:`view_file` treats matching `__model_knowledge__` file IDs as authorization, before `has_access_to_file()`:The same forged `meta.knowledge` is also trusted outside the tool path. `has_access_to_file()` iterates the caller's accessible models and returns true when a model's `meta.knowledge` contains the requested file ID:This branch is not restricted to read, so it also satisfies the `write` check that `DELETE /api/v1/files/{id}` performs. The same missing validation applies to the import path (`POST /api/v1/models/import`) and the update path, not only create.PoCThe PoC executes the real `Models.insert_new_model()` sink and the real `view_file()` authorization branch with fake database/file adapters. It first confirms that the attacker-owned model stores a forged victim file ID in `meta.knowledge`, then confirms `view_file()` denies the same victim file without model knowledge but discloses content when the forged model knowledge entry is present.Result:Exploit SketchAttacker has permission to create or update workspace models.Attacker creates a model with:Attacker chats with that model using native/built-in tools and invokes `view_file` for `VICTIM_FILE_ID`.The tool returns the victim file's extracted text content despite the attacker not owning or otherwise having access to the file.Recommended FixValidate `meta.knowledge` on every model write path: create, update, and import. For entries with `type == "file"`, require direct ownership, admin role, or `has_access_to_file(file_id, 'read', user, db=db)` before storing the entry. Validate the import payload before its surrounding try/except so a rejection surfaces as `403`, not `500`.Do not let `view_file()` treat `__model_knowledge__` as an authorization bypass; it should still enforce ownership/admin/`has_access_to_file()` per file ID. File deletion should require ownership, admin, or explicit write/delete access, not a read-derived model association.ConsolidationPer our Report Handling policy this consolidates independent reports of the same model `meta.knowledge` file-ID laundering flaw:Read via forged `meta.knowledge` on model create, through the built-in `view_file` tool: @0xEr3n (earliest filing).Distinct paths demonstrated by @5yu4n: the import endpoint (`POST /api/v1/models/import`), and cross-user read and deletion through the file API (`GET` / `DELETE /api/v1/files/{id}`) via `has_access_to_file()`'s model branch.Fix validates `meta.knowledge` ownership on create, update, and import; blocking the forged entry closes both read and delete. One CVE for the consolidated advisory.
CVSS v3.1 score: 7.1