https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 21:03:48 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-335439 EUVD-2026-335439 https://cve.radiocsirt.org/vuln/euvd-2026-335439 https://cve.radiocsirt.org/vuln/fkie_cve-2026-59212 <p>Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 before 0.10.0, _verify_knowledge_file_access only checked read access while file write and delete routes later trusted object-derived access through writable model meta.knowledge entries, allowing a user with read-only knowledge file access to upgrade to file write or delete operations. This issue is fixed in version 0.10.0.</p> <p>Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 before 0.10.0, _verify_knowledge_file_access only checked read access while file write and delete routes later trusted object-derived access through writable model meta.knowledge entries, allowing a user with read-only knowledge file access to upgrade to file write or delete operations. This issue is fixed in version 0.10.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-59212 https://cve.radiocsirt.org/vuln/ghsa-2xwm-4h2q-ggfx <p><strong>Affected:</strong> PyPI: open-webui</p> <p>## Summary</p> <p>Current `main` and `v0.9.6` still allow an authenticated user to turn read-only access to another user&#39;s file into write/delete access by attaching that file ID to an attacker-controlled workspace model.</p> <p>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, &#34;read&#34;, user)`. The file write/delete routes later trust `has_access_to_file(file_id, &#34;write&#34;, user)`, and that function grants access through any writable model whose `meta.knowledge` contains the file ID.</p> <p>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.</p> <p>## Technical Details</p> <p>`backend/open_webui/routers/models.py::_verify_knowledge_file_access()` accepts model `meta.knowledge` file entries when the caller can read the file:</p> <p>```python if not await has_access_to_file(file_id, &#39;read&#39;, user, db=db): raise HTTPException(...) ```</p> <p>`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:</p> <p>```python for model in await Models.get_models_by_user_id(user.id, permission=access_type, db=db): knowledge_items = getattr(model.meta, &#39;kn…</p> <p><strong>Affected:</strong> PyPI: open-webui</p> <p>## Summary</p> <p>Current `main` and `v0.9.6` still allow an authenticated user to turn read-only access to another user&#39;s file into write/delete access by attaching that file ID to an attacker-controlled workspace model.</p> <p>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, &#34;read&#34;, user)`. The file write/delete routes later trust `has_access_to_file(file_id, &#34;write&#34;, user)`, and that function grants access through any writable model whose `meta.knowledge` contains the file ID.</p> <p>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.</p> <p>## Technical Details</p> <p>`backend/open_webui/routers/models.py::_verify_knowledge_file_access()` accepts model `meta.knowledge` file entries when the caller can read the file:</p> <p>```python if not await has_access_to_file(file_id, &#39;read&#39;, user, db=db): raise HTTPException(...) ```</p> <p>`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:</p> <p>```python for model in await Models.get_models_by_user_id(user.id, permission=access_type, db=db): knowledge_items = getattr(model.meta, &#39;kn…</p> https://cve.radiocsirt.org/vuln/ghsa-2xwm-4h2q-ggfx https://cve.radiocsirt.org/vuln/pysec-2026-3588 <p><strong>Affected:</strong> PyPI: open-webui</p> <p>## Summary</p> <p>Current `main` and `v0.9.6` still allow an authenticated user to turn read-only access to another user&#39;s file into write/delete access by attaching that file ID to an attacker-controlled workspace model.</p> <p>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, &#34;read&#34;, user)`. The file write/delete routes later trust `has_access_to_file(file_id, &#34;write&#34;, user)`, and that function grants access through any writable model whose `meta.knowledge` contains the file ID.</p> <p>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.</p> <p>## Technical Details</p> <p>`backend/open_webui/routers/models.py::_verify_knowledge_file_access()` accepts model `meta.knowledge` file entries when the caller can read the file:</p> <p>```python if not await has_access_to_file(file_id, &#39;read&#39;, user, db=db): raise HTTPException(...) ```</p> <p>`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:</p> <p>```python for model in await Models.get_models_by_user_id(user.id, permission=access_type, db=db): knowledge_items = getattr(model.meta, &#39;kn…</p> <p><strong>Affected:</strong> PyPI: open-webui</p> <p>## Summary</p> <p>Current `main` and `v0.9.6` still allow an authenticated user to turn read-only access to another user&#39;s file into write/delete access by attaching that file ID to an attacker-controlled workspace model.</p> <p>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, &#34;read&#34;, user)`. The file write/delete routes later trust `has_access_to_file(file_id, &#34;write&#34;, user)`, and that function grants access through any writable model whose `meta.knowledge` contains the file ID.</p> <p>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.</p> <p>## Technical Details</p> <p>`backend/open_webui/routers/models.py::_verify_knowledge_file_access()` accepts model `meta.knowledge` file entries when the caller can read the file:</p> <p>```python if not await has_access_to_file(file_id, &#39;read&#39;, user, db=db): raise HTTPException(...) ```</p> <p>`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:</p> <p>```python for model in await Models.get_models_by_user_id(user.id, permission=access_type, db=db): knowledge_items = getattr(model.meta, &#39;kn…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3588