A critical authorization bypass vulnerability discovered in Open WebUI has exposed thousands of multi-user deployments to silent, permanent file destruction.
Tracked as CVE-2026-45671 and assigned GHSA-26g9-27vm-x3q8, the flaw allows any authenticated user, regardless of role, to permanently delete files owned by other users without leaving any audit trail.
The vulnerability, rated High severity with a CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H), affects all Open WebUI versions up to and including 0.8.12 and was patched in v0.9.0 released in April 2026.
The vulnerability lives inside has_access_to_file()the central authorization function in backend/open_webui/rout,ers/files.py. Every file operation, read, modify, and delete, passes through this function before execution.
The problem is a shared-chat branch within that function that unconditionally returns True the moment it finds any shared chat referencing the target file:
chats = Chats.get_shared_chats_by_file_id(file_id, db=db)
if chats:
return TrueThis single block ignores two essential security checks. First, it never verifies whether the requesting user owns or participates in the shared chat, or if any authenticated account on the instance passes.
Second, the access_type parameter, which distinguishes between read and write (delete) operations, is accepted by the function but never inspected inside this branch.
The result: sharing a chat is a routine collaboration action that inadvertently transforms every referenced file into a deletion target for every user on the platform.
The delete endpoint (DELETE /api/v1/files/{id}) compounds the problem by lacking a secondary ownership check that the content-update endpoint includes, creating a direct path from authorization bypass to irreversible data removal from the database, the disk, and all knowledge base associations.
File UUIDs are long and impractical to brute-force, but an attacker doesn’t need to guess them. Any user with read access to a shared knowledge base can retrieve all file UUIDs within it by calling:
GET /api/v1/knowledge/{kb_id}/filesIn enterprise deployments where knowledge bases are intentionally shared across teams, this endpoint hands attackers a complete list of valid targets.
The attacker then calls DELETE /api/v1/files/{file_id} with any valid JWT token from a regular user account. Security researcher @Inar1Dev published a proof-of-concept script (poc.py) written entirely in Python 3’s standard library that confirms accessibility, deletes the file, and verifies permanent removal via an HTTP 404 response, all without special tooling.
While the original proof-of-concept focused on file deletion, the same flawed has_access_to_file() gate also governs read (GET /api/v1/files/{id}) and content modification (POST /api/v1/files/{id}/data/content/update) endpoints.
This means the practical impact extends to unauthorized read access and content tampering on any file referenced in any shared chat, making this a read + modify + delete triple bypass through a single vulnerable function.
The consequences are particularly severe for deployments using Open WebUI’s Retrieval-Augmented Generation (RAG) knowledge bases.
When a document is deleted, the associated knowledge base silently degrades; there is no user-facing indicator that content is missing.
AI responses relying on those knowledge bases become silently incomplete or inaccurate. Adding to the danger, the delete operation records no audit trail identifying the responsible user, making forensic investigation difficult or impossible after the fact.
The vulnerability was resolved in the commit 2e52ad8ff (“refac: shared chat”), shipped in v0.9.0. The fix introduced a dedicated shared_chats table and replaced the blind branch with a permission-aware, user-aware access model.
The update has_access_to_file() is now located in backend/open_webui/utils/access_control/files.py calls AccessGrants.get_accessible_resource_ids to filter shared-chat IDs to only those the requesting user has an explicit grant on, whether through ownership, group membership, or a public share link. The gate now also correctly respects the access_type parameter.
Any organization running Open WebUI 0.8.12 or earlier with chat sharing enabled which is the default configuration, should treat this as an urgent remediation:
- Upgrade immediately to Open WebUI v0.9.0 or later
- Audit file activity logs for unexpected deletions before patching
- Review knowledge base integrity for missing documents in RAG pipelines
- Restrict knowledge base sharing temporarily until the upgrade is complete
FAQ
Q1: Which versions of Open WebUI are affected by CVE-2026-45671?
All versions up to and including 0.8.12 are vulnerable; v0.9.0 and later are patched.
Q2: Does an attacker need admin privileges to exploit this vulnerability?
No, any authenticated user account with a standard (user) role can exploit the flaw.
Q3: Can deleted files be recovered after exploitation?
No, the delete operation permanently removes the file from the database and the disk, and from all knowledge base associations, with no built-in recovery mechanism.
Q4: Is chat sharing required to be actively used by the attacker, or just enabled on the instance?
The attacker only needs another user on the instance to have shared a chat referencing the target file; the attacker themselves does not need to share anything.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
