# Open WebUI: shared-chat branch ignores access_type, allowing unauthorized file deletion

Open WebUI's has_access_to_file() shared-chat branch ignores access_type and user identity, letting any authenticated user delete or modify files referenced in any shared chat.

- Payout: Research
- Severity: high
- Program: Open WebUI
- Found by: Inar1Dev
- Disclosed: 2026-05-14
- CVE: CVE-2026-45671
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-26g9-27vm-x3q8
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-26g9-27vm-x3q8
- Tags: area:web domain:web impact:data-leak impact:integrity kind:research platform:ghsa sev:high tech:python technique:source-review vuln:access-control vuln:idor

**Target:** DELETE /api/v1/files/{id} and related file endpoints in Open WebUI backend
**Root cause:** has_access_to_file() returns True whenever any shared chat references the file, without checking the requesting user's identity or the access_type (read vs write) being requested.
**Steps:**
1. Victim creates a knowledge base, uploads a document, attaches it to a chat, and shares the chat.
2. Attacker obtains the file UUID via `GET /api/v1/knowledge/{kb_id}/files` if they have read access to the KB.
3. Attacker calls `DELETE /api/v1/files/{id}` with their own JWT; has_access_to_file() returns True via the shared-chat branch.
4. File is permanently removed from DB, disk, and KB associations; subsequent GET returns 404.
**How found:** Code review of has_access_to_file() revealed the shared-chat branch returns True unconditionally, ignoring both the access_type parameter and the requesting user; the delete endpoint lacks a secondary ownership check unlike the content-update endpoint.
**Exploitation:** Any authenticated user with a valid JWT and a target file UUID (leaked via shared KB file listing) can issue DELETE /api/v1/files/{id}; the shared-chat branch of has_access_to_file() authorizes the write operation regardless of ownership, permanently destroying the file with no audit trail.
**Escalation:** Same gate also authorizes GET read and POST modify endpoints, so the bypass yields read + modify + delete on any file referenced by any shared chat.
**Insight:** When an authorization helper takes an access_type parameter, verify every branch actually inspects it — a shared-resource shortcut that returns True early often silently authorizes write/delete paths meant only for read.

## Proof of concept (copied exactly from the original report)

**PoC script invocation deleting target file**

```
python3 poc.py --url http://<host>:3000 --file-id <target-file-uuid> -t <attacker-jwt>

The PoC script (attached as `poc.py`):
1. Authenticates as the attacker
2. Confirms the target file is accessible via `GET /api/v1/files/{id}/data/content`
3. Deletes the file via `DELETE /api/v1/files/{id}`
```

**Knowledge base file UUID disclosure request**

```
GET /api/v1/knowledge/{kb_id}/files

This returns metadata for all files in the KB, including their UUIDs.
```